Sorry, I meant to start a new thread, not hijack. Let me do it now.
A couple more questions (by the way Leslies description was awesome
and makes total sense).
Interfaces
a) When creating a generic outbound or inbound interface with an
extrernal system - do you build based upon the archetypes only - i.e.
provide as many values possible? or your specializations? or is this
all mute and we stick with HL7?
b) Do templates or specializations or archetypes define workflow
e.g.
record results, based upon results collect additional information or not?'
In the case were a doc just wants to replicate a paper form but not
improve it would I build a template or stick with Archetypes? So
implementing a form like this:
Regarding your form - you could try to archetype it, but it would likely
only be usable in that particular department of that particular
organisation, and there are data elements on the form that are best modelled
in different archetype classes - observation, evaluations, instructions etc.
- very messy, won't work
Without a doubt, the template is the ideal solution.
On the NHS CFH Clinical models wiki there are currently 12 Maternity and 18
Emergency composition templates - http://svn.openehr.org/knowledge/TAGS/dev-uk-nhs/Lorenzo_3.5/pub/ContentRele
ase-1.0.1/templates/gen/html/index.html that demonstrate how the template
aggregates archetypes for a given purpose - from capturing a record for
chest pain in the Emergency Department through to recording a Partogram for
a woman in labour, and the rest. And of course, the Blood Pressure
archetype used in the ED is the same one as the one in the Partogram -
re-used for a different purpose, but recording BP in both contexts will show
up in a later BP query.
And of interest is that in the Emergency Generic Acute Presentation template
there are 60 discrete archetypes that represent all of the concepts that
need to be recorded for a generic record visit to an NHS ED - from history
of presenting complaint, past history, family history, examination,
investigations and followup.
Greg,
Interfacing with existing systems using messaging such as HL7 is something I
have been doing for some time now and we have a considerable amount of
infrastructure to make it happen. Ocean Informatics was involved in an
Interoperability Demonstration (similar to the IHE Demonstration at HIMMS)
at the recent MedInfo international health informatics conference in
Brisbane. We demonstrated accepting HL7 V2 lab, ADT and referral messages
from other vendor system and stored them as openEHR compositions using both
base and specialised archetypes. The process involved building a template
of those archetypes for each message type and mapping the HL7 into those
templates. We also demonstrated converting an openEHR composition directly
committed in an openEHR repository to HL7 CDA. The original creation of the
composition utilised a template but the actual conversion to CDA simply
utilised the knowledge in the archetype models to understand and develop the
transformation to the associated HL7 clinical statements within the CDA.
This CDA document was then submitted to another vendors IHE XDS repository.
This same process can be used to create HL7 v2 messages or any other format
you wish.
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
I guess where I am going with this is for my system I was considering:
a) Integrate the archetypes and templates as system content.
b) Create an outbound interface that is EHR compatible.
c) Provide (web?) services to allow EHR queries.
So for I wonder if b) is necessary to be 'OpenEHR compatible' or is
supporting HL7 through an engine like Mirth sufficient?
It is our experience that if you support the openEHR models internally you can plug and play many interfaces - so HL7 will be good for the early years - when there is another openEHR instance, then it will be better to go native!
