Retrieve, Locate, and Update Service Avatar
  1. OMG Specification

Retrieve, Locate, and Update Service — Closed Issues

  • Acronym: RLUS
  • Issues Count: 5
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Locate Resources by Resource Parameter (SFM 5.3.1)

  • Key: RLUS_-1
  • Legacy Issue Number: 14810
  • Status: closed  
  • Source: Consultant ( Giorgio Cangioli)
  • Summary:

    It is not clear to me if and how might be realized the SFM 5.3.1 Locate Resources by Resource Parameter operation.

    Infact neither the locate() operation nor the list() seem used for metadata resources retrieval.

    Is it assumed that metadata retrieval should be realized using the list() operation "playing" with the semantic signifiers; or, an extensions of the locate() operation is needed ?

  • Reported: RLUS 1.0b2 — Sat, 21 Nov 2009 05:00 GMT
  • Disposition: Resolved — RLUS 1.0
  • Disposition Summary:

    Not an OMG issue (needs to be addressed by HL7).

  • Updated: Sat, 7 Mar 2015 03:51 GMT

(SFM 5.1) Administrative and Management Interface

  • Key: RLUS_-2
  • Legacy Issue Number: 14811
  • Status: closed  
  • Source: Consultant ( Giorgio Cangioli)
  • Summary:

    It is not clear to me if and how might be realized the metadata resource management (according the meaning of the cap. 5.1 of the SFM document: create, update;....an RLUS entry).

  • Reported: RLUS 1.0b2 — Sat, 21 Nov 2009 05:00 GMT
  • Disposition: Resolved — RLUS 1.0
  • Disposition Summary:

    Not an OMG issue (needs to be addressed by HL7).

    Revised Text:

    • none -

    Disposition: Closed – No Change

  • Updated: Sat, 7 Mar 2015 03:51 GMT

RLUS: single targetNamespace "urn:eis.hssp.org" is used

  • Key: RLUS-2
  • Legacy Issue Number: 14855
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    A single targetNamespace "urn:eis.hssp.org" is used in all of the following
    machine readable files for the RLUS submission, for both the wsdl and the schema used by the wsdl:

    · CCD.xsd - An XML schema for the HL7 v.3 Continuity of Care Document. This is a semantic signifier for Patient Profiles, uses targetNamespace="urn:hl7-org:v3"
    · HW_POCD_MT00040.XSD - An XML schema used to define data types used in the CDA and CCD document which is used as a semantic signifier for RLUS, uses targetNamespace="urn:hl7-org:v3"
    · RLUSExpression.xsd - An XML schema for the representing queries through the RLUS interface, uses targetNamespace="urn:expression.hssp.intel.com"
    · RLUSOrderService.WSDL - WSDL for how to support clinical orders with the RLUS interface, both wsdl definitions and schema in types use targetNamespace="urn:order.hssp.intel.com" and
    <xs:import namespace="urn:RLUStypes.hssp.intel.com" schemaLocation="RLUSTypes.xsd"/>
    <xs:import namespace="urn:hl7-org:v3" schemaLocation="CCD.xsd"
    · RLUSPatientService.WSDL - WSDL for how to support patient histories and profiles with the RLUS interface, both wsdl definitions and schema in types use targetNamespace="urn:patient.hssp.intel.com" and
    <xs:import namespace="urn:RLUStypes.hssp.intel.com" schemaLocation="RLUSTypes.xsd"/>
    <xs:import namespace="urn:hl7-org:v3" schemaLocation="CCD.xsd"
    · RLUSTypes.XSD - XML schema which lists the RLUS data types to support the RLUS interfaces, uses targetNamespace="urn:RLUStypes.hssp.intel.com" and
    <xs:import namespace="urn:expression.hssp.intel.com" schemaLocation="RLUSExpression.xsd"/>
    <xs:import namespace="urn:hl7-org:v3" schemaLocation="CCD.xsd"

    The target Namespaces used are not OMG rooted.

    Solution proposed by originator:

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

    If the two schemas using namespace "urn:hl7-org:v3" are under the control of this submission, they too should be changed to use OMG 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: RLUS 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — RLUS 1.0b2
  • Disposition Summary:

    Remove Intel copyright notice, as it is in violation of the LOI conditions. Then, change the namespaces to conform to the OMG namespace convention

  • Updated: Sat, 7 Mar 2015 03:51 GMT

EIS: single targetNamespace "urn:eis.hssp.org" is used

  • Key: RLUS-3
  • Legacy Issue Number: 14857
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    A single targetNamespace "urn:eis.hssp.org" is used in all of the following
    machine readable files for the EIS submission, for both the wsdl and the schema used by the wsdl:

    wsdl file swpEISMgmtAndQueryInterface.wsdl (platform dependent)
    wsdl file swpEISAdminEditorInterface.wsdl (platform dependent)
    wsdl file EISMgmtAndQueryInterface.wsdl (platform independent)
    wsdl file EISAdminEditorInterface.wsdl (platform independent)
    wsdl file EISMetaDataInterface.wsdl (platform independent)

    Common wsdl:message definitions and schema definitions are repeated across several of the wsdl files. This will cause a maintenance headache. These should be pulled out into separate wsdl and/or xsd files which can be referenced by wsdl:import, xsd:import or xsd:include element in each of the 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: RLUS 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — RLUS 1.0b2
  • Disposition Summary:

    At this time, change only the namespaces to adopt the OMG namespace conventions. The OMG EIS specification is part of HSSP project between HL7 and OMG. Further minor changes to the leading HL7 functional specification are anticipated and need to be incorporated by a follow-on RTF. Refactoring of the WSDL files to improve maintainability should be deferred and bundled with these anticipated changes to minimize disruption of already existing implementations of the current OMG EIS specification.

  • Updated: Sat, 7 Mar 2015 03:51 GMT

Errors in Transcription of EIS document

  • Key: RLUS-1
  • Legacy Issue Number: 13934
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    The truth table for the FindEntitiesByTraits section 8.6 was apparently copied from the one for RegisterEntityWithIdentity section 8.1, and it doesn’t even bear a passing resemblance to the corresponding truth table at section 4.6 in the version 1.3 document

  • Reported: RLUS 1.0b1 — Fri, 15 May 2009 04:00 GMT
  • Disposition: Resolved — RLUS 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:51 GMT