Optionality -HL7 version 3.0 has very little optionality which is one of the weaknesses of version 2.x. The RIM which is the basis for version 3 has no concept of optionality. The need for a value in the message is defined by trigger event rather than the data definition. This has led to better message definitions. Optionality in version 3 is replaced by “Conditionality” which means that the presence of a data field in the message may be allowed or not depending on the value of another field..
Model based - Version 3.0 is based on an object oriented model; Reference Information Model (RIM) to create message specifications. The model provides an explicit representation of the semantic and terminology relationships that is present in the information present in the fields of HL7 messages.
Model based - Version 3.0 is based on an object oriented model; Reference Information Model (RIM) to create message specifications. The model provides an explicit representation of the semantic and terminology relationships that is present in the information present in the fields of HL7 messages.
Conformance - HL7’s version 3.0 is primarily intended to be a stable and definite standard which will allow vendors to conform to a universal standard. This will allow regulatory agencies and local HL7 bodies where applicable test the applications to an agreed standard and provide a conformance certificate to the vendor.
Technology independent - Version 3 introduced the concept of “Implementable Technology Specification (ITS)” which describes the process of instantiating a message from its definition. Currently XML is the widely used and probably only one ITS available publicly. But unlike V2.x; HL7V3.0 ITS allows other technologies to be used for messages e.g. UML ITS, JavaBeans etc.
Electronic Health Record - HL7 version 3 offers a much more efficient method to communicate information between clinical systems by providing the context of information in the messages which is not possible in version 2.x. It also provides the ability to collect clinically coded information for the purpose of maintaining Electronic Health Record for sharing clinical data consistently across organizations. Version 3 is emerging as the standard of choice for creating national EHR’s due to the level of semantic interoperability provided by it.
Localization and Refinement: HL7 Inc allows a balloted HL7V3.0 specification to be further constrained for region specific profile aided by a HL7 Inc Affiliate. This localization of messages allows quick deployment of HL7V3.0 for an organization or region to meet their specific needs.
You say:
ReplyDeleteVersion 3 is emerging as the standard of choice for creating national EHR’s due to the level of semantic interoperability provided by it.
This is what is claimed by the HL7 organisation. But do you have any evidence that it is true? As documented at
http://hl7-watch.blogspot.com/
I have been unable to provide examples of national IT organizations that are actually building anything in V3.
Thanks Barry; its indeed a honour that some one as eminent as you came to my site and commented on what i said.I have visited your site many times and in fact i think i commented on one of your articles some time back
ReplyDeleteWell iam working on a well known national programme which you often criticise on your site. I have implemented succesfully HL7V3.0 messaging fot his national programme even if its only for retrieving and updating demographics from a national Master Patient Index and booking appointment slots. The same national project also succesfully implemented electronic transmission of prescriptions using HL7V3.0 and i have been involved with that as well.It works great. Yes i know we have problems with clinical messages but its more to do with a decisionto use a particular coding mechanism than to do with HL7. Ofcourse they now moved to CDA for clinical messages but at a high level with usage of clinical statements the distiction between CDA R2 and HL7V3.0 clincial messages is quite blurred.Even then the clinical messages used by the primary care do use pure HL7V3.0 clinical statement message pattern messages.
Finally even within the RHIO-NHIN prototype implementation being done by Accenture at the level of the participating care organization, Accenture
provided multiple data extraction mechanisms to convert local data into standard, HL7
v3 message formats.
Yes we did face a lot of practical problems with HL7V3.0 even for demographic messages but credit should go to CFH Comms and Messaging team which did a commndable job
Ananda,
ReplyDeleteI am pleased to hear that you have successfully implemented HL7 V3.0 messaging for retrieving and updating demographics from a national Master Patient Index and booking appointment slots.
My English colleagues tell me that, to make things work, it was necessary to create a substantial rebuild of HL7 V3.0 for UK purposes. I would be interested in hearing your thoughts on this matter, especially in the light of the remarks here:
http://hl7-watch.blogspot.com/2007/11/versions-of-rim_16.html
Barry
ReplyDeleteYes thanks for pointing out the blog post to me; i agree to an extent on what you said. Thats why in my response i commended the CfH Comms and Messaging team efforts in getting it right. Iam not the right person to defend HL7 because iam not even a member of HL7 but as some one who extensively used HL7 i will respond to your question.
The reality of the situation is that demogrpahics exchange in CFH world is not between two healthcare systems in a hospital but between healthcare systems in hosital and national demographics repository. The requirement is to syncrhonise the demographics in national repository with the local system at the point of patient contact. This is a CFH specfic requirement which is publicly available at
http://www.connectingforhealth.nhs.uk/systemsandservices/demographics/pds?searchterm=PDS
The message interactions involving demographics cannot obviously use the interactions of Person Administration module of normative edition of HL7 Inc which are more of inter departmental system exchange. If you look at the MIM-Message Implementation Manual of CFH which is available for download at HL7-UK website it clearly says that the Messages and Data Types are based on the HL7 v3 RIM. Realm specific constraints are applied where appropriate and are identified within the documentation.
I would take it the realm specific constraints is what is being mentioned when the effort into specifying the standards for messages is being mentioned
This is a advantage of HL7V3.0 where HL7 Inc allows a balloted HL7V3.0 specification to be further constrained for region specific profile aided by a HL7 Inc Affiliate. This localization of messages allows quick deployment of HL7V3.0 for an organization or region to meet their specific needs.