Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
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. Sam Damon - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Karsten, The advantage is that there will be no 3 or 4 competing standards, but just one. It seems enough. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 29 Nov 2004, at 23:44, Karsten Hilbert wrote: We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards. The advantage of which is what, exactly ? Karsten -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 537 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041130/1329336d/attachment.bin
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Hi, We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 29 Nov 2004, at 20:56, Damon Berry wrote: Sam, Thanks for the helpful comments Sam Heard wrote: 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, - 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) 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. -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1658 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041129/e6c62e81/attachment.bin
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards. The advantage of which is what, exactly ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Dear all, I am not sure whether this is premature but I curious as to which part of an OpenEHR compliant EHR-S will enforce the constraints that are embedded in an archetype model - I note the use of the term data validator on the web site - Will the kernel in an OpenEHR server parse data (for instance to assess completeness of a communicated extract) using some sort of constraint processor - or will this be up to individual implementers to sort out? Also, is there any ongoing implementation / validation work on how to map archetype-based communications into (for instance) decision support services? Will it be practical to incorporate legacy DSS systems or will it be necessary that a DSS function within an OpenEHR-compliant EHR-S is built from scratch around the OpenEHR models? Finally - how would you go about developing an OpenEHR-compatible instrument interface? What steps would be taken in order to feed raw measurements from an instrument into the EHR? I suspect that this would involve some of the following activities. I would like your guidance on how the scenario continues, and/or whether it is in the scope of the work. AT DESIGN / IMPLEMENTATION TIME DOMAIN SPECIALISTS AND DEVELOPERS... - create an archtype with the appropriate constraints to comply with data provenance, context requirements etc. - implement an instrument interface that produces (in cooperation with an OpenEHR server) the minumum set of data surrounding the measurement that is required by the archetype AT RUN TIME THE INTERFACE... - constructs a message including all of the context information (time stamp, origin,etc) surrounding the raw measurement - checks for completeness of the data - facilitates(?) a check for correctness of the data - ?? - passes the information to the EHR-S where it is incorporated into the EHR (automatically? or only with signed human consent?) Best Regards, Damon Berry -- This message has been scanned for content and viruses by the DIT Information Services MailScanner Service, and is believed to be clean. http://www.dit.ie - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
