Archetype constraints and interfacing instruments/DSS to an OpenEHR system.

Technical (archive)
1

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

2

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

3

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

4

Hi,
We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards.

Gerard

5

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

6

We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards.

The advantage of which is what, exactly ?

Karsten

7

Karsten,

The advantage is that there will be no 3 or 4 competing standards, but just one.
It seems enough.

Gerard

8

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

9

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:

10

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

11

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