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
