On Fri, 12 Sep 2003, Thomas Beale wrote:that's a big question, so here is a small answer;-)
...
the problem with this is that a) the HL7 RIM is not a particularly goodIn that case, do you think HL7 v3 is sufficient to support portable medical records between EMR systems? Could it prevent the same barriers that HL7 implementions ran into?
model of the content in an EHR, so using a (necessarily RIM-based) HL7
message between EHR systems is going to require transforms at either
end, where errors can obviously occur. Sending EHR Extracts or using
published EHR APIs to communicate is likely to be much safer.
Thomas,
Obvously you have put much deep thought into comparing these approaches. Many projects, especially the OIO project, will greatly benefit from your knowledge.
Could you kindly educate us on the foundamental differences between "HL7 RIM" vs. "EHR Extract" vs. "EHR API" ?
- the RIM is an analysis pattern of the concepts Act/Act_relationship/Participation/Role/Role_relationship/Entity. Actually, I would say it is two analysis patterns joined together - the Act one, and the Entity/Role/Role_relationship one - a kind of demographic analysis pattern. Its purpose is as an abstract model from which to build specific message models - HL7 believes everything can be expressed as a specialisation (i.e. a constrained form) of the RIM - i.e. they see all clinical information as an Act.
- the EHR Extract is a package of Compositions extracted from the EHR. CEN ENV 13606 specifies this; openEHR also specifies one. Eventually these might become one, or the openEHR one a clean superset of the other.
- and EHR API is a query and modification interface to the EHR, enabling applications and other services to access a given EHR server.
- thomas
