Issues for Mailing list of the joint EIS and RLUS 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 13934: Errors in Transcription of EIS document
Issue 14810: Locate Resources by Resource Parameter (SFM 5.3.1)
Issue 14811: (SFM 5.1) Administrative and Management Interface
Issue 14855: RLUS: single targetNamespace "urn:eis.hssp.org" is used
Issue 14857: EIS: single targetNamespace "urn:eis.hssp.org" is used

Issue 13934: Errors in Transcription of EIS document (eis-rlus-ftf)

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

The Definitions table in section 7.1 has the lines removed, which makes it more difficult to read. 
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. 
The table lines were removed from both truth tables, which made them almost impossible to read.  This affects sections 8.1 and 8.6. 
Section 8.6 has a [ds1] which was a flag to a reviewers comment, and should have been removed from final text.  I was the reviewer, and had asked whether we needed a way to request different types of output (result sets). 
Section 9.6 has a [ds2] which was a flag to a reviewers comment, and should have been removed from final text.  I was the reviewer, and had asked whether more explanation was needed. 
Section 10.6 has a [ds3] which was a flag to a reviewers comment, and should have been removed from final text.  I was the reviewer, and had asked whether this could be better represented by an arrayOf[Sequence]. 
Section 12 has a [ds4] which was a flag to a reviewers comment, and should have been removed from final text.  I was the reviewer, and had flagged this section for more work. 
Section 12 ends by referencing machine readable files in OMG document number health/xxx, and the that line should have had the correct document # inserted. 
Section 12.1 has a [ds5] which was a flag to a reviewers comment, and should have been removed from final text.  The comment was actually empty in the supplied document. 
Tables 1 and 2 in Section 12.3.1.1 have the lines removed, making them more difficult to read. 
Section 13.2 has a [ds6] which was a flag to a reviewers comment, and should have been removed from final text.  I was the reviewer, and had flagged this section for more work.
Resolution:

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 ?

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

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?

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?