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.

A minimal conformance profile that only requires the “evaluate” operation within
the “Evaluation” interface has been defined. Also, the conformance profiles have
been simplified to include only this “evaluation only” conformance profile and a
full conformance profile supporting all defined operations. The previous
intermediate profile (the “Core” profile) was removed because it was
functionally very close to the Complete profile, (ii) additional profiles could be
specified outside of the scope of this specification by DSS providers if desired,
and (iii) the two remaining profiles appear to be the ones to which implementers
are gravitating.

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.

This issue has been resolved in the PSM by correcting the relative order of
elements as recommended

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

It is now noted that a RESTful Web service PSM is under consideration for future
specification.

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.

Further clarified approach to security in SOAP Web service PSM. In particular,
select security considerations included in the RFP response but not included in
the beta 1 specification have been re-introduced. Also, it is now explicitly noted
that an implementer may extend the provided WSDLs to incorporate WS-Security
conformance and still be considered compliant with the specification.

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?

The recommended changes have been made. Specifically:

• The common WSDL definitions have been pulled into a new WSDL
  (dssBaseComponents.wsdl). This WSDL is then referenced through a
  wsdl:import into each of the WSDLs that correspond to the
  conformance profiles.
• The namespaces for the schemas and WSDLs have been separated.
• The targetNamespace has been changed to be an OMG rooted
  namespace.
• For the namespaces, URLs that resolve to a RDDL which has pointers
  to the relevant WSDLs and XSDs are now provided, as described in
  the document authored by Tom Rutt on this topic, obtained form
  http://xml.coverpages.org/OMG-Rutt-NamespaceProposal-
  20090917.pdf

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

The contents of OmgDssSchema.xsd have been grouped and alphabetized in a
manner derived from the package structure used in the PIM. Auto-generated
classes could be logically packaged in accordance with the suggested package
structure if desired.

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.

Non UTF-8 characters, which consisted of special apostrophes, were removed
from the schema annotations by rewording the comments appropriately in all PIM
and PSM models. Also, the encodings of all XSDs and WSDLs developed in this
specification were set to UTF-8.
Also, along with this typo correction, a number of additional miscellaneous
corrections were made, as detailed below.

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.

The use of xs:any has been replaced by the use of xs:base64Binary in the SOAP
XML Web Services PSM.

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

An InteractionIdentifier class with the recommended information has been added
to all operations as an input

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.

The Exception base class has been renamed DSSException.