Actually, my proposal is not to use archetypes for CDA (although I think
it would be sensible if HL7 did that), but to define a 'document
architecture' within openEHR, i.e. a coherent part of the openEHR
specification stack. We already have what is needed - it is essentially
the schema for the COMPOSITION, possibly with an envelope around it.
Problems with HL7 CDA:
* level 3 is based on RIM structures, which are a very problematic
way of representing structured clinical information
* the demographics are included inline, repetitively
* there is no defined query methodology or semantics
* it doesn't support distributed versioning and merging
Solutions exist for all of this in openEHR, and packaging it within an
openEHR Document Architecture (ODA) would provide a better alternative
for health computing for the future.
Dealing with existing HL7 CDAs is another matter - there will always be
a cost and complexity associated with them, and this can be dealt with
by various means using archetypes and templates. But I don't see it as
the way of the future. We need properly defined, self-consistent health
information semantics for all types of communications and
representations within an e-health computing environment.
- thomas
On 04/01/2011 21:06, Sam Heard wrote:
>
> Dear All
>
> Thomas has raised the issue of an openEHR Clinical Document off line.
> The key point is that there are some issues for openEHR and HL7 that
> require aligning a) the CDA documents that flow around the system with
> b) EHR systems and openEHR. Most existing systems will bring CDAs in
> as documents and treat them pretty much like letters (text and PDF) --
> with smarter systems getting any structured information and offering
> to incorporate this data into the system.
>
> CDA is a step forward conceptually and is used more and more as the
> basis for communication. There are still a number of issues that need
> to be addressed and also opportunities for openEHR to provide solutions.
>
> 1.Will the data be structured consistently enough for safe processing
> by receiving systems? This remains uncertain except in highly
> controlled environments. The problem is that there are limited tools
> to assess the correctness of data which is largely specified in
> implementation guides. openEHR archetypes and templates can provide
> schemas through a formal process that will allow validation of data
> and also specific transforms to and from CDA (on a per archetype
> basis). This may improve utility, data quality and consistency of
> representation across different CDA documents.
>
> 2.CDA documents contain document management information. This is not
> sufficiently complex to allow exchange of information - it requires
> serial output from a single source. Such a scheme is appropriate for
> lab results and other one-way feeds but not for sharing a health
> summary or other key persistent data. The openEHR specifications are
> much more attuned to requirements for health summaries including
> medication lists, past history, obstetric management, operation
> planning, care plans etc. We need to work with others to make sure the
> difference between a collection of documents and an EHR is well
> understood.
>
> 3.CDA documents have participations that are fully populated. This
> includes identifying information about the client which would not
> usually be included in data in an EHR. This has implications for
> anonymisation. The EHR is the environment where identifying
> information needs to be managed and it seems unlikely that documents
> that are shared will contain overtly identifying data for many
> transactions in the future. Shared EHR repositories seem like a better
> and safer approach but again, we need to look at the requirements and
> understand the advantages of different approaches. The limited ability
> to populate other participations (at the composition and entry level)
> with structured data is an issue in openEHR where demographic data
> will not be shared between systems and probably should be put forward
> as a change request to allow data about doctors and other people to be
> shared without a transfer of demographic data. The CCR has an
> intermediate approach which may be better than the CDA approach as it
> allows multiple use of the same personID at different points in the
> same document/composition.
>
> 4.Unstructured HTML or PDF or text is a feature of many health record
> documents. OpenEHR has a datatype that allows for storage of this sort
> of data. At present it is not related to the DV_TEXT and so it is not
> possible to have formatted text as a text field. There is also a
> PARAGRAPH type that is a mixture of formatted and DV_TEXT. Natural
> language processing is attempting to turn clinical records into
> post-coordinated SNOMED codes. This is interesting work and some form
> of this approach is likely to be helpful in the future. I do not think
> openEHR or CDA are well suited to meet these requirements where
> natural language (and formatted) text is mixed in with structured data
> that can be processed. CDA runs the two in parallel while openEHR
> forces explicit structure where required. The openEHR approach is
> undoubtedly safer but it is worth considering the best approach to
> meet these needs.
>
> 5.Archetypes assume the openEHR reference model. In the current tools
> this is somewhat problematic as designers have to know a little about
> the reference model -- but it is also the most important feature as
> consistency is critical for safe computing. Mistakes were made early
> on in not assuming the reference model features and being explicit
> about some features when there was actually no constraint. We have
> learned about this and the next round of tooling will need make it
> easier for designers and not create constraints where none are required.
>
> The main opportunity for which everyone will be grateful is if we can
> use openEHR archetypes to create consistent CDA and provide the
> transforms required to move seamlessly from CDA to openEHR and back.
> This provides a single source of truth and is what many people are
> seeking. What we need to take this further is:
>
> 1.A standard transformation of a template of an openEHR Composition to
> HL7 CDA -- converting EHR attributes to CDA attributes -- that does
> not require explicit modelling of data that is already captured in the
> openEHR RM. The transformation may require renaming of openEHR RM
> attributes that are specific for that the template as CDA documents
> may have different labels that are the same thing in an EHR system
> (e.g. a prescription may have a 'prescriber' whereas a document may
> have an 'author' where both are the legal creator of the document).
>
> 2.An archetype to CDA transform (and back) that labels the CDA data in
> a way that it is clear which archetype this CDA data conforms to. This
> is needed for each archetype and should be available on CKM.
>
> The openEHR RM should also consider adding a CLUSTER to participation
> to allow structured data or include participation data in the
> composition. Other_participations may be the location for this with
> IDs that are referenced within the composition -- but this is not the
> planned use and will need some consideration. Some may argue that this
> should be from the demographic model but I do not think so.
>
> Thoughts?
>
> Cheers, Sam Heard
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110105/4535dd9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110105/4535dd9c/attachment.jpg>
