Sam Heard wrote: > Damon > > This is important to consider.... > >>> I believe that DSS >>> groups will be a major player in determining the final archetypes >>> that are >>> agreed at a high level. >>> >> It seems to me that in the same way, archetypes will have great >> impact on >> the development of future EHR-compatible instrument interface >> standards. If >> instruments and instrument interfaces are required to provide >> information >> that is complete enough to be integrated into the EHR, then additional >> context information will need to be appended as the measurement >> values are >> recorded. >> >> Lets assume that a typical existing instrument interface was not >> designed to >> produce shareable EHR extracts - a safe bet in my view. Result: missing >> context info. So to ensure compatibility either, > > > It is not critical that the instrument give all the context as you > point out below. > >> >> - the instrument interface is revised by the instrument vendor to >> satisfy >> the associated archetypes >> OR >> - an adapter on the EHR side of the interface adds the required >> context >> information prior to submitting it to the EHR-S proper. (not very nice) > > > I guess you know this from experience.....we would see the clinician > setting up the monitoring - this is the only context I think that > would not come from the machine - the protocol information and > measurements should be enough then. > >> OR >> - some compromise is reached on the completeness of the archetype. >> (dangerous) >> >> OK - maybe I am exaggerating - but it would be interesting to pick a >> "legacy" instrument standard (say crusty old ASTM 1394-91) and see >> how it >> holds up. > > > If you know something well, lets use that. I would not see an extract > as the way to go - but it would be appropriate if a whole session was > captured in another environment and then sent to the EHR - perhaps in > a catheter lab. > > The norm for instruments would be to create one or two (or three) > entries. Pulse oximetry is a good example.
The data sent from an instrument to an openEHR EHR server would not be an EHR Extract (since it isn't by definition an extract from an EHR at the source), but could easily be an archetyped ENTRY, just as you would find in the EHR. It would be easy to define XML or other message definitions for this based on the openEHR archetypes. At some point in the near future, I see the archetype tools doing this. Then you have complete harmony, from messages coming from devices (archetyped ENTRIES) to the EHR (archetyped COMPOSITIONs, SECTIONs, ENTRIES) to the screen (templated & archetyped). Only one set of semantic models behind everything (archetypes); all that is needed at the message side is a defined service interface, and for the GUI side, a mechanism for adding visual information to logical templates (which currently say what is on a form, but not where it is). Neither of these should be under-estimated of course - I have already seen how complex the latter can be in a couple of systems. But on the other hand, having a single formal set of clinical models, and one information model underlying the whole lifecycle of clinical information is surely attractive. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
