Mike,
Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and is precisely what you want. HL7 version 3 and CDA will be to unstable for some time to come. HL7 doesn't adopt the GEHR (CEN) two model approach. Artefacts based on the present HL7 version 3 RIM will prove to be unimplementable as a system or object. It is my opinion that a real co-operation between HL7 CDA and CEN/TC251 TF EN 13606 is of importance. CEN and GEHR have a lot to offer to HL7. But will this be recognised? Gerard On 2002-06-08 11:59, "Mike Mair" <mikemair at es.co.nz> wrote: > Thanks Sam, > > You said: > > you cannot communicate unless you speak the same language. We have had HL7 >> for many years, we have had many other means of communicating information >> and yet we are unable to communicate EHRs. This is, in my view, because > the >> information models underlying systems vary so much. > > There are so many ontologies, and more being invented all the time. I agree > that you need to share some to communicate, but that can be negotiated. The > reality we have to deal with is polyontology, and there are tools being > developed to navigate between them. (eg the Ontology Inference Layer OIL and > DAML http://www.daml.org/ ) > >> The CDA is a good approach as it uses text as its data layer - and we can >> all accept text. We can even display it with a transform - which is nice. >> The problem is that there is a need to increase the complexity of the >> information so far beyond text to get true interoperability of EHRs > > If we start by sharing the CDA as HES, we can migrate to more structured > data sharing as the level 2-3 CDA is developed. We are not trying for full > interoperability between EHRs at this stage - too hard! We can start simple > and grow into more complete interoperability with further iterations both of > the standard, and participant software. >> > - we need to have a shared model of the EHR - implemented in >> various ways and with greater or lesser transformation required for data > and >> semantic interoperability. > > Why not just limit the 'standard' to dictionaries of archetypes (informed by > ontologies), and containers to convey them. We can use the access control > and document navigaton features of the CDA to convey the clinical objects > harvested at the health event. The level 2-3 CDA is a hybrid, part document, > part container. A Health Event Summary, a Transaction, a EHR Extract, and > a CDA document have very similar properties, including 'Persistence, > Stewardship, Wholeness, and human readiablity' (from the CDA specs). > Standards work is about achieving a shared way of doing something, so if we > all just adopt this 'low hanging fruit' the 'standard' will be served. > > There's work enough to do to get a shared design for the clinical objects. > Thomas Beale suggests that the CDA might have a role integrating legacy > systems into his EHR, which might be fine if the rest of us are 'legacy'. We > can use the CDA for our baseline interoperability between all systems > including GEHR systems. > > < text and schema is not enough - the EHR >> needs to be expressed primarily within tools that will ensure that the XML >> is conformant. I don't expect everyone to agree with this but there is >> increasing empirical evidence. > > The question is, whose ontology, whose schemas, and that's just where we > are at. I think it is time to actually get the specs for clinical objects, > and start making some dictionaries, incorporating work already done, eg the > 3M work, the GEHR archetypes, Dicom objects etc. However,it is possible > there will be many ontologies even for clinical material. I note that the > technique of Natural Language Processing is being applied to medical free > text especially in the US, delivering a dictionary of medical 'facts' .. > These would be a source of structured data and the CDA could be an exchange > format for documents that are secondarily 'structured' in this way. This > would generate more work for ontology integration tools! > > We might get to a situation more like Natural Language, where 'meaning is > use', and terms come into existence, mutate, pass out of use, yet still > mange to 'mean' for their participant communities. > > I am still not convinced that it is an EHR structure that has to be shared > for meaningful communication. Both aspects of interoperabiliy, functional > and semantic, can be served without sharing an EHR structure. > > Regards > > Mike Mair (NZ HL7 User Group) > > >> >>> -----Original Message----- >>> From: http://www.daml.org/ >>> [mailto:owner-openehr-technical at openehr.org]On Behalf Of Mike Mair >>> Sent: Thursday, 6 June 2002 5:30 AM >>> To: Thomas Beale >>> Cc: openehr-technical at openehr.org >>> Subject: Re: The concept of contribution >>> >>> >>> Dear Tom, >>> >>> Greetings. I have been following your work for some time. It >>> seems we have a >>> great opportunity now to get somewhere with all this, especially with > the >>> convergence that you yourself identify in your 'Manifesto' document on > the >>> GEHR site. I mean your concept of 'containers' and 'objects'. >>> >>> I agree with it, but I was looking to the HL7 CDA to be the basic HES >>> Template, and then the objects (archetypes) fit in that. Bob >>> Dolin from the >>> HL7 Structured Documents Group has described a way of doing this. Their >>> model might have a different emphasis from your 'versioned transaction' >>> concept. All 'Health Event Summaries' would have the same basic > structure, >>> from simple free text documents to the Level 3 CDAs. These can >>> then provide >>> a searchable data warehouse. >>> >>> I have often thought that the distinction between 'persistence' >>> and 'event' >>> transactions was unnecessary. I don't think we should be constructing an >>> ideal EHR at all. We should be working on a communication >>> standard. I agree >>> that a HES or RDS system is not an EHR, but it should not try to be. >>> Instead, it might provide the currency to make EHRs out of. That's > what >>> vendors are for. There can also be open source developers. If we just >>> capture the essentials, in containers of objects from all the >>> health events, >>> that will give all the base data we need. The HES may start off > primitive >>> (mainly free text), but will come to contain harvested data objects >>> (including prescription objects, family history objects etc.). >>> >>> There will need to be some recognition of different levels of 'grain' in >>> data objects. I have often found your work confusing on this point. > Blood >>> Pressure (or intraocular pressure) will make fine grained data objects. >>> Whole examinations (like 'diabetic foot exam') are a level of grain >>> coarser. There is an argument that templates of that level should not be >>> mandated or registered at all, being in the province of the clinician to >>> employ or change as required. The may in fact be mandated for certain >>> groups, but that is more for administrative control rather than medical >>> virtue. >>> >>> If you put clinical objects in a standard format basket (the CDA), and > put >>> the meta data in the header, you can use the header for retrieval >>> and access >>> control. The standard could be as simple as that. There could be 'order >>> objects' which might give more context information about how data was >>> captured, but they would be optional. >>> >>> This concept of the standard would not prevent you from continuing work > on >>> your wonderful opensource EHR, and I wish you all success with >>> it, but there >>> are other EHR models, and many as yet undreamed of. I think the >>> communication >>> 'standard' could and should be simpler as outlined above >>> >>> Regards >>> >>> Mike Mair >>> NZHUG (NZ HL7 User Group) >>> >>> Sent: Wednesday, June 05, 2002 12:17 PM >>> Subject: Re: The concept of contribution >>> >>> >>>> [Forwarded response from Sam Heard] >>>> >>>> Thomas Beale wrote: >>>> >>>>> >>>>> In the current issue (3.11) of the EHR reference model, we have >>>>> documented the concept "contribution" as being that collection of >>>>> TRANSACTIONs corresponding to a single clinical session. That is to >>>>> say, due to a patient contact, there could be the following new >>>>> TRANSACTIONs: >>>>> >>>>> - patient contact (this causes a new VERSIONED_TRANSACTION) >>>>> - update to family history transaction (new version in existing >>>>> VERSIONED_TRANSACTION) >>>>> - update to current medications (new version in existing >>>>> VERSIONED_TRANSACTION) >>>>> - update to plan (new version in existing VERSIONED_TRANSACTION) >>>>> - etc >>>>> >>>>> So the contribution in this case would be four TRANSACTIONs, each in >>>>> distinct VERSIONED_TRANSACTIONs, and each having identical details > in >>>>> the CLINICAL_CONTEXT object. >>>>> >>>>> Now... contributions are the unit of change of the record. The >>>>> question is, do we need to be able to easily find them after the > fact, >>>>> or is it not really important. If it is not important most of the >>>>> time, then we can do nothing, sicne they will in fact be findable by >>>>> looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT >>>>> objects. However, this will be slow, as it means going through all >>>>> transactions in the entire record. If it is important to be able > find >>>>> contributions quickly (as I have theorised in the past, and Andrew >>>>> Goodchild at the DSTC suggests), then we need to formalise the > concept >>>> >>>> >>>> I do not think that we do but I am happy to hear what people >>> have to say. >>> I >>>> think it is the same function as putting the date back - ie a > historical >>>> date. In fact there is no reason why these things should all be >>> changed at >>>> once - a computer might be left on for an hour and then the rest is >>>> committed - what is that? >>>> >>>> >>>>> Andrew has also suggested that EHR extracts are really a kind of >>>>> "contribution", since they are effectively a bag of TRANSACTIONs to > be >>>>> applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not >>>>> due to the same clinical session (they could be anything, depending > on >>>>> what the requestor asked for), their addition to the receiving EHR >>>>> will in fact be a contribution. >>>> >>>> >>>> This is a merge_audit and I do not think that they have the >>> same status in >>>> any way. >>>> >>>> >>>>> If we are to formalise this concept, we need to have use cases > showing >>>>> when/why contributions need to be handled as explicit entities. >>>>> >>>>> If we can prove the need, the following architectural possibilities >>>>> suggest themselves: >>>>> - use FOLDERs to act as contributions, i.e. every time a > contribution >>>>> goes in, make a new FOLDER that contains the references to those >>>>> TRANSACTIONs >>>>> - define CONTRIBUTION as a new subtype of FOLDER and use it as above >>>>> - if we consider a contribution to be the equivalent of an outer >>>>> transaction in a nested transaction, then we might create a new >>>>> TRANSACTION for each controbution, whose contents are links to the >>>>> other transactions in the contribution, >>>>> - we could always add links to the first TRANSACTION in a > contribution >>>>> pointing to the other TRANSACTIONs in the group. >>>>> >>>>> thoughts? >>>>> >>>> >>>> NO way Jose - can I be any stronger than that? >>>> >>>> - Sam >>>> >>>> >>>> - >>>> If you have any questions about using this list, >>>> please send a message to d.lloyd at openehr.org >>>> >>> >>> - >>> If you have any questions about using this list, >>> please send a message to d.lloyd at openehr.org >>> >> >> - >> If you have any questions about using this list, >> please send a message to d.lloyd at openehr.org >> >> > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
