Gerard, I feel that the idea of the EHR as being essentially a data base made up of bits of messages is a fundamental misconception that is at the bottom of many of our problems in health informatics. As first approximation it works for GPs but sadly, it does not scale across the whole healthcare spectrum.
Any set structured information is designed for a primary purpose. This is true of databases, documents, classifications and models. Any attempt to use that information outside its original purpose is fraught with danger. While it is true that a collection of documents can be thought of as an electronic record, we have to take a lot of care when the information which they contain is reused outside the original context of a message. CEN and HL7 messages are just that - messages - from someone, to someone and about someone at a moment in time. They have more in common with electronic mail than with database structures. Any attempt to take information from a message and put it into a database is potentially dangerous and needs to be done with a real understanding of the data. This can only be done when messages are rooted in very clearly defined use cases. The scale of the problem is illustrated by thinking very clearly about ALL of the potential users of medical records. In UK the Dept of Health recognises more than 60 medical specialties. If you add in all of the other clinical specialties then you have at least 100 distinct groups of people who have their own specialised ways of working and requirements, including audit and quality control issues, which ultimately determine how they need their data to be structured. They cannot all use just one structure, however much we would like this to be the case. Kind regards Tim -- Tim Benson Abies Ltd, 24 Carlingford Road, London NW3 1RX, UK +44 (0) 20 7431 6428, tb at abies.co.uk > From: Gerard Freriks <gfrer at luna.nl> > Reply-To: Gerard Freriks <gfrer at luna.nl> > Date: Fri, 07 Jun 2002 10:47:13 +0200 > To: Sam Heard <sam.heard at flinders.edu.au> > Cc: <openehr-technical at openehr.org> > Subject: Re: The concept of contribution > > Hi, > > > A personal view. > > HL7 (V2 and v3) and CEN messages can be considered fragments of an EHR. > Most often these fragments are used in the logistics of the patient or > healthcare provider. They integrate systems within an organisation. > CEN/TC251, HL7 CDA, GEHR and Structured Reporting (Dicom) are efforts to > record the information fragments in a document. A document with the prime > goal of registering a narrative based on the fragments. The narrative of the > Healthcare provider telling the medical story of the patient and his > problems. Secondly the narratives in a document must be transferable to > other documents. > All the relevant information fragments put together is the EHR. > GEHR, CEN, HL7 CDA and SR provide the syntaxes to tell the story. The > fragments (including the Terminologies) are the words. By adopting all the > same syntaxes medical stories become Interoperable provided that the > fragments are semantically interoperable. > I consider the Transactions as paragraphs. And the Contribution the set of > paragraphs that are committed (attested by signing off) to the record. > Each paragraph has an header and is collected in chapters with a title. > The headers and titles help the navigation and ordering of the information. > > Work by CEN and GEHR show that this goal is completely feasible. > HL7 CDA developments are lacking behind because of a predominant focus on > CDA level 1 document messages. > > > > With regards, > > > > Gerard > > > > > On 2002-06-07 05:28, "Sam Heard" <sam.heard at flinders.edu.au> wrote: > >> >> Mike >> >> Thanks for your letter. I just want to say something I think is important - >> 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. >> >> I have seen so many large projects to enable exchange of health information >> over the years fail - I know believe that we need to share a basic >> information model to allow this to take place. >> >> 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 that the >> text gets very complex and not human readable - though a transform is still >> possible to display it. >> >> So, in summary - 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. And, text and schema is not enought - 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. >> >> Cheers, Sam >> >>> -----Original Message----- >>> From: owner-openehr-technical at openehr.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 > > -- <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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
