# Archetype constraints and interfacing instruments/DSS to an OpenEHR system. **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2004-11-19 12:21 UTC **Views:** 3 **Replies:** 10 **URL:** https://discourse.openehr.org/t/archetype-constraints-and-interfacing-instruments-dss-to-an-openehr-system/14103 --- ## Post #1 by @Damon_Berry 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 --- ## Post #2 by @Sam Damon I am sure a number of responses will come you way but\.\.\. > 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? The validator \(of compositions\) is available at any point in the system \- it is required by the server when receiving data from any or any untrusted site \- and by any application building openEHR data\. That is why we want to have this available as an open source and collaborative development\. Thomas Beale built a validator in Eiffel some years ago now as a proof of concept\.\.\.and the DSTC have an advanced component running in the HealthConnect trial in Australia\. The CHIME group at the UK \- with Thomas and European collaborators \- are building the Java component at the moment\. We should see this available in alpha form in the 2nd Q of 2005\. > Also, is there any ongoing implementation / validation work on how to map > archetype\-based communications into \(for instance\) decision support > services? We have designed the archetype methodology \- from day 1 \- to support queries into the data\. Accessing any data point is possible using a path notation\.\.\.\.and we hope that this will become standardised across all openEHR systems ASAP\. It is also possible to transform this into XQuery for XML based compositions \(or EHRs\)\. However, the only large openEHR based data store at the moment is the DSTC trial data in Brisbane Australia \- The CHIME group have data based on their earlier work\. So we have limited groups able to work on this at present \- hopefully it will grow soon\. Do you have XQuery experience? > 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? It should be quite straight forward to change the \{\} part of DSS statements to openEHR archetype based queries\. It assumes that the information model on which they are built is reflected in the basic archetypes agreed\. I believe that DSS groups will be a major player in determining the final archetypes that are agreed at a high level\. > 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? None at present \- although the OBSERVATION class is well equipped for this purpose\. > 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 Correct > 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 > \- ?? I guess we would see 2 ways to go here\.\.\.\.a message or a composition\. The openEHR model has this contribution class for allowing construction of a composition that is then stored\. It is more of a transaction based model than the current message model ie the data is in the form required by the EHR\. Yes \- the correctness in so far as the archetype constraints apply\. > \- passes the information to the EHR\-S where it is incorporated into the EHR > \(automatically? or only with "signed" human consent?\) We have the ability to have an agent sign this if that is what the normal practice is\. Cheers, Sam Heard --- ## Post #3 by @Damon_Berry 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\. Damon --- ## Post #4 by @system Hi, We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards\. Gerard --- ## Post #5 by @Sam 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 --- ## Post #6 by @Karsten_Hilbert > We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards\. The advantage of which is what, exactly ? Karsten --- ## Post #7 by @system Karsten, The advantage is that there will be no 3 or 4 competing standards, but just one\. It seems enough\. Gerard --- ## Post #8 by @Karsten_Hilbert > The advantage is that there will be no 3 or 4 competing standards, but just one\. Hopefully\. I am unconvinced as to mankinds ability to actually do any such thing \(come up and be happy with one standard where one could have 3 or 4\)\. Karsten --- ## Post #9 by @lakewood Hi All, Change is an ever\-present factor, requirement and necessity\. This is true in Healthcare as it is in many other human endeavors\. Standards that prohibit or avoid change at some point become obsolete\. Regards\! \-Thomas Clark Karsten Hilbert wrote: --- ## Post #10 by @system Hi, One thing I know that in this time frame CEN/TC251, HL7 and ISO/TC215 co\-operate harmonized standards are/will be produced\. It is without any doubt that nothing is forever\. We expect that our co\-operation will produce a series of standards in Medical Informatics that will last longer than ever and will be able to evolve and improve\. How many alternate and competing HTML \(or XTML\) or TCP/IP standards do you want? Gerard Freriks --- ## Post #11 by @thomas.beale 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 --- **Canonical:** https://discourse.openehr.org/t/archetype-constraints-and-interfacing-instruments-dss-to-an-openehr-system/14103 **Original content:** https://discourse.openehr.org/t/archetype-constraints-and-interfacing-instruments-dss-to-an-openehr-system/14103