Dear Sam,
Some of your comments with respect to handling the discrete data are tackled in the HL7 Care Record message. This has with respect to the CDA level 3 content the same structure. My hypothesis is that a lot of the problems you mention can be tackled by focusing on the Care Record part of HL7 as addition to CDA. Vriendelijke groet, William Goossen directeur Results 4 Care -----Original Message----- From: Sam Heard <[email protected]> To: 'For openEHR technical discussions' <openehr-technical at openehr.org> Sent: Tue, Jan 4, 2011 10:06 pm Subject: Clinical Documents, openEHR, 13606, CDA and CCR 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110104/0636419b/attachment.html>
