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 ?

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

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).

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

Revised Text:

• none -

Disposition: Closed – No Change

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?

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

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?

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.

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

No Data Available