${taskforce.name} Avatar
  1. OMG Task Force

Clinical Decision Support Service 1.0 FTF — All Issues

  • Key: CDSS
  • Issues Count: 10
Open Closed All
All Issues

Issues Descriptions

Evaluation only conformance profile

  • Key: CDSS-10
  • Legacy Issue Number: 15641
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Fri, 24 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EvaluationRequest and IterativeEvaluationRequest content ordering

  • Key: CDSS-9
  • Legacy Issue Number: 15634
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider RESTful service specification

  • Key: CDSS-8
  • Legacy Issue Number: 15633
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

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

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Security Issues

  • Key: CDSS-7
  • Legacy Issue Number: 15632
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DSS: single targetNamespace "urn:dss.hssp.org"

  • Key: CDSS-1
  • Legacy Issue Number: 14856
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    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?

  • Reported: CDSS 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    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
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Too many defined elements within one package name

  • Key: CDSS-4
  • Legacy Issue Number: 15629
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

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

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non UTF-8 character in schema comments

  • Key: CDSS-3
  • Legacy Issue Number: 15628
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of xs:any data type for payload

  • Key: CDSS-5
  • Legacy Issue Number: 15630
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All Defined Operations

  • Key: CDSS-2
  • Legacy Issue Number: 15624
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

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

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of "Exception" as a class name in the model

  • Key: CDSS-6
  • Legacy Issue Number: 15631
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    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.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    The Exception base class has been renamed DSSException.

  • Updated: Fri, 6 Mar 2015 20:58 GMT