Andrew Ho wrote:

On Fri, 12 Sep 2003, Thomas Beale wrote:
...


In 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?



the problem with this is that a) the HL7 RIM is not a particularly good
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" ?

that's a big question, so here is a small answer;-)

- 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





Reply via email to