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
> Best Regards,
> Damon Berry
>
>
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
