DEV WG Discussion Rosetta Containment Hierarchy

(DEV WG Wiki Home)

Comments invited to Device Communications "Rosetta Containment Hierarchy" - deadline 2009-10-31

In mail to HealthCare Devices List of Wed, 30 Sep 2009 18:24:28, Melvin REYNOLDS wrote:

Dear colleagues,

Please excuse multiple copies of this mail received if you are members of more than one device-communication related list.

In our meetings in Atlanta last week we briefly reviewed the attached important document, prepared by Paul Schluter initially for the enterprise-integration oriented work of IHE-PCD implementation.

You will note that the potential reach of the methodology described is greater than facilitation of relating proprietary terms to the ISO/11073(-101xx) RefIDs and codes; it has the potential to make render the domain information model (11073-10201) redundant.

Some might see this to be an advantageous simplification of an apparently complex standard, others might see it to be a potentially disadvantageous relaxation of the specifications associated with use of the model. Please therefore review the document and comment in the attached form.

Please think about the following issues in particular (though you are welcome to address others):

• scope,
• suitability, extensibility and scaleability,
• suggested strategy for completion and publication (i.e. organisation (IEEE, IHE, etc. - and deliverable type).

On the basis of your comments we will seek to define the most appropriate route from here.

Lastly, please submit your comments by 'reply to all' before October 31 2009.

Thanks - and best regards,

Melvin.

[ An attachment, application/msword: RCH.1g.doc : data size 202kb, was included here ]

[ An attachment, application/msword: Comment template RCH.1g.doc : data size 32kb, was included here ]

In mail of Thu, 1 Oct 2009 11:14:24, Malcolm Clarke wrote:

Dear Melvin

I am not sure of your point. Paul has developed a "presentation" (much like MDER) to represent the device message using HL7 constructs in order to preserve semantics within the message.

As such, it represents the DIM (hierarchy of objects and attributes) of the device, and rather than making the DIM obsolete, carries the 11073 (classic and PHD) into the HL7 world. That is why it appears elegant. If there are issues, it would be how an HL7 system will cope with and understand PCD presentations of a hierarchical model (DIM) in an otherwise flat HL7 V2 model world.

Perhaps we can discuss so that I am more clear of your issue, as I am not sure if I am missing something.

Regards Malcolm

In mail of Thu, 1 Oct 2009 13:38:49, "Schluter, Paul (GE Healthcare)" wrote:

Melvin, Malcolm and Todd,

Malcolm is correct -- there is no intention to replace the DIM. They key goal is to provide "cookbook clarity" for implementers regarding the IHE PCD-01 "observation hierarchy" in an easy to understand yet rigorous representation that could be used for documentation and conformance testing. The RCH would be used together with the co-constraints expressed in the RTM.

So, I am fine with posting it to a larger audience "as is". Although there are some fine points regarding cardinality (e.g. top-level MDS is "0..1" or "0..*", depending on the validation technology used, with "0..*" being more appropriate for a collection of any number of devices used on behalf of the patient) the basic approach looks very promising, and can be readily extended to support events and other data streams/types.

Best regards,

Paul

In mail of Sat, 3 Oct 2009 22:36:20, Malcolm Clarke <malcolm.clarke@brunel.ac.uk> wrote:

Dear Melvin

The main discussion on this topic is whether we should have a pure presentation of PHD, ie its actual object hierarchy is indicated by the hierarchy level in the OBX, or whether we artificially map PHD to an equivalent hierarchy level as classic, so that numeric value attributes are consistently reported at the same hierarchy level in PHD as in PCD, in order to have consistent mapping and interpretation in HL7.

Our discussion in Atlanta was whether the missing levels of PHD should be included in the message explicitly, or if they may be allowed to be inferred implicitly if omitted.

Regards

Malcolm