This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Health Care Devices (DEV) WG"

From HL7Wiki
Jump to navigation Jump to search
(Added: Discussion topic - Rosetta Containment Hierarchy)
(Comments invited to Device Communications "Rosetta Containment Hierarchy" - deadline 2009-10-31)
Line 41: Line 41:
 
==Discussion topics==  
 
==Discussion topics==  
  
#'''''  Comments invited to device communication "Rosetta Containment Hierarchy" - deadline 2009-10-31'''''   
+
#'''''  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: ''
 
''In mail to HealthCare Devices List of Wed, 30 Sep 2009 18:24:28, Melvin REYNOLDS wrote: ''
Line 67: Line 67:
 
Melvin.  
 
Melvin.  
  
[ An attachment, application/msword: RCH.1g.doc : data size 202kb, was included here ]  
+
[ [http://www.hl7.org/Library/Committees/healthcaredevices/N0262_WG7_RCH.1g.pdf 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 ]  
+
[ [http://www.hl7.org/Library/Committees/healthcaredevices/N0262c_WG7_Comment%20template%20RCH.1g.doc An attachment, application/msword: Comment template RCH.1g.doc : data size 32kb, was included here] ]  
  
  

Revision as of 11:11, 2 October 2009

The Health Care Devices (DEV) working group seeks to facilitate integration of health care device information throughout the health care enterprise, enabling more efficient and accurate processing of device-related data and ultimately resulting in improved patient safety and quality of care.

To accomplish this integration, the working group is actively engaged in...

  • Establishing standardized version 2.x and version 3 messaging profiles to support health care device interoperability at the enterprise level
  • Harmonizing device data models between HL7 and other organizations including ISO/IEEE 11073
  • Harmonizing and coordinating device terminology usage within HL7 components
  • Support revision and harmonization of the Clinical and Laboratory Standards Institute (CLSI ) Point of Care Test (POCT) and laboratory automation standards
  • General coordination and harmonization between HL7 and other national and international organizations involved in health care device informatics and interoperability


Note: This group was formerly (pre-2005) known as LAPOCT.

See also: Health Care Devices WG on www.HL7.org

Please join the Health Care Devices list server to receive WG status updates and participate in the group's activities.


Coordination

Given the strong partnership between the DEV WG and other organizations, the following links may also be of interest:

- IHE PCD Web Page
- published Technical Framework components
- wiki pages capturing work-in-progress

Agendas

Agendas are also posted on the health care devices web page.

Minutes

The minutes can also be found on the DEV WG minutes web page.
  • <minutes of WGMs>

Discussion topics

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