Issues for Mailing list of the Clinical Decision Support Service 1.0 Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 14856: DSS: single targetNamespace "urn:dss.hssp.org"
Issue 15624: All Defined Operations
Issue 15628: Non UTF-8 character in schema comments
Issue 15629: Too many defined elements within one package name
Issue 15630: Use of xs:any data type for payload
Issue 15631: Use of "Exception" as a class name in the model
Issue 15632: Security Issues
Issue 15633: Consider RESTful service specification
Issue 15634: EvaluationRequest and IterativeEvaluationRequest content ordering
Issue 15641: Evaluation only conformance profile

Issue 14856: DSS: single targetNamespace "urn:dss.hssp.org" (dss-ftf)

A single targetNamespace "urn:dss.hssp.org" is used in all of the following 
machine readable files for the DSS submission:

wsdl file dss_minimum_functional_profile.wsdl (subset of full set of operations)
wsdl file dss_core_functional_profile.wsdl (subset of full set of operations)
wsdl file dss.wsdl (full set of operations)

xsd file HsspDssSchema.xsd (xs:include in wsdl:types element of each wsdl file)

The common wsdl:message definitions are repeated in each of the three wsdl files.  This will cause a maintenance headache.  These should be pulled out into a separate wsdl file which can be referenced by a wsdl:import into each of the three wsdl files above.

Is it necessary to keep the same namespace for both the schema and wsdl?  It might be easier for ongoing maintenance to give the schema a different target namespace from the wsdl descriptions.  This is a design decision that the FTF should consider.

Of greater significance, the targetNamespace used is not an OMG rooted namespace.

Solution proposed by originator:

The FTF should use OMG rooted namespaces, as opposed to continuing to use
hssp.org rooted namespaces?

Rather than using urn values for namespaces, the OMG has recommended strongly, the 
use of URLs which resolve to a RDDL file which has pointers to the 
wsdl and/or schema files which define that namespace?

Need an interaction identifier and timestamp for all defined operations to avoid issues with logging under multi-threaded situations

Schema HsspDssSchema.xsd has a non-processable, non UTF-8 character (right-handed single quote) in comments in a number of locations.  This causes failure of some code generators and compilers.

Use of a single package name limits logical packaging of elements and causes problems for auto-generated classes.

Standard approach for this type of content in similar healthcare interoperability specifications (eg, IHE specifications) usually specify contained payloads as a Base64 encoded string.  The current approach with xs:any results in creation of a DOM object for payload, which results in unnecessary processing overhead.

Use of the name "Exception" as a class name in the model causes problems with Java code generators, due to confusions with the java Exception class.

Consider further clarifying approach to security in SOAP Web service PSM.  For example, consider explicitly noting that an implementer may extend the provided WSDLs to incorporate WS-Security conformance and still be considered compliant with the specification. 

Consider providing RESTful PSM or noting that a RESTful PSM is under consideration for future specification.

For the EvaluationRequest and IterativeEvaluationRequest, KMEvaluationRequest and IterativeKMEvaluationRequest should precede dataRequirementItemData, so that the knowledge module being used is apparent before potentially very lengthy payload data are provided.  This may make it possible for a CDSS to ignore data not needed for a requested rule, thereby improving performance.

There have been many requests to support a minimal conformance profile that requires only select operation(s) of the Evaluation interface.  Such a conformance profile should therefore be added.