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
