I'll preface my comments by stating that after a very useful discussion with Andrew Goodchild today at the DSTC, I have agreed to write up a 2 or 3 page discussion paper on the subject of contributions with diagrams, whch I will put on the web. This will describe change management of the EHR seen from the configuration management paradigm, and describe what we think a "contribution" really is. I will publish this in the next couple of days, to help the discussion...
Mike Mair wrote: >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. > It will be searchable at some levels only. A CDA document is pretty close to what we are calling a contribution. The differences are: - with an openEHR contribution, multiple transactions can be updated due to an interaction with the record,.e.g family history, plan etc. This is good from the point of view of having this information in thematically meaningful buckets. With CDA, all the content is in the document. If you want to build a picture of family history or current medications or care plan - especially if you want it nicely arranged under an agreed set of headings - it is going to be challenging... - due to the level 1,2,3 conformance levels of CDA, any particular query searching for a particular kind of information, e.g, facts about family history will potentially work well for level 3 documents, but nothing can be said about the level 1 and level 2 documents in the repository, since in general there is no way for the level 3 query to work. Likewise, queries on level 2 attributes will only work for level 2 and 3 documents; only level 1 queries will correctly return results for all documents. This is not a criticism - it is exactly the expected behaviour of a repository of documents whose job is to provide different levels of structuring capability, due to the need to cope with input of varying quality. Health event summaries appear (according to our work so far) to be a relatively easily archetypable family of structures. Some of their informatino will be what we call "persistent" information, i.e. what is found in the persistent transactions (what I called "thematic" transactions above). >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 > Interestingly, as we work with this concept, it becomes more and more obvious. Consider the EHR as a repository of documents or information entities, some of which are defined by purpose or theme, such as the typical transactions for "family history", "current meds", "lifestyle", "social history", "vacc history", "therapeutic precautions", "plan", "problem list", etc. These are what we call persistent transactions, and it is very clear that most EHR applications - both interactive and batch - will be hitting these transactions all the time. In openEHR we are in the business of specifying the semantics of information in health records. It is true that some of the discussion goes beyond the remit of defining a communication standard. As long as this is clear, I don't think anyone has a problem with this. It is formally differentiated by the specification of EHR_EXTRACT versus EHR - the former is the basis for communication, while the latter is the basis for systems. But it is extremely useful to talk about what EHR systems need to be able to do, in order to figure out what the communication model should look like - I would go so far as to say that no-one is going to be able to design a good commuication standard without thinking about what is in the systems from which information comes (others disagree with this but that's the nature of debate!) >that a HES or RDS system is not an EHR, but it should not try to be. > I would agree >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.). > Interestingly, in discussions at HL7 Atlanta, the gulf between free text and structured information emerged - there appears to be a much greater free text data problem in the US than elsewhere, presumably due to the transcribing culture there. Designers of systems in the UK (Prodigy for example) would say that a good user interface simply obviates the problem of masses of free text. In our (admittedly limited) GPCG case studies here in Australia (OASIS, medical director data, sundry others) we haven't had a problem with struture - most of the data is structured. The structure isn't necessarily great, and the challenge has been to "discipline" it according to good archetypes. So no-one at this stage has suggested using the CDA for EHR as such. I'm not saying it could not be used - maybe when we get more into hospitals we will find it comes into use as a way of getting EHR subissions from legacy applications to an openEHR EHR server... >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. > agree - in openEHR, this is an ENTRY containing a LIST_S, containing 2 ELEMENTs, each with a value (if there is a protocol, it is another LIST_S, with the relevant ELEMENTs for "cuffsize" etc). >Whole examinations (like 'diabetic foot exam') are a level of grain coarser. > agree - in openEHR, the heading structure is an ORGANISER_TREE and ORGANISERs. >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. > Well, whether or not they are mandated as such depends on the specific segment of the clinical community. This does not mean that they can't exist and shouldn't be used at all. All we are saying is how to produce them and use them. Whether they are mandatory is completely up to professional bodies and practitioners agreeing to agree on them. (And don't forget - archetypes are not fixed templates - you can easily design in the ability to have everything optional, extra trees of information etc). >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. > The level 1 header data is nearly the same as the TRANSACTION revision history information in the REVISION_HISTORY object; we have been working on closing any remaining gaps, but they are very small now. One thing I will say is that we have tried to base our work on an emerging theory of contexts (see the "Design Principles for the EHR" document) rather than ad hoc considerations. It isn't perfect, but is standing up pretty well to some hard questioning... >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 > I think we are much closer to it than you realise. Currently in openEHR, an EHR_EXTRACT, which is what you usually want to transmit consists of: - the requested TRANSACTIONs - demographic snapshots for all demographic entities mentioned in the transactions - access control and other security/consent data - terminology control data EHR_EXTRACTs are the unit of request and reply between conformant EHR systems. The most likely use of a CDA document is from a non-compliant system (which may have very little or a lot of structuring) _to_ an EHR system. The first thing an openEHR system would probably do with it is to pull it apart and apply its information as updates to the relevant transactions. There may be uses for output as well - the CDA group would have a better idea of the use cases here. As for other EHR models, I don't know of too many that aren't particular system models, and I also don't know of many that are based on the notion of clear separation of information representation and knowledge concept models (i.e. reference model and archetypes). Models that I know of include: - various models from U. Manchester including Alan Rector's PEN&PAD and others, COSMOS etc - various models from Switzerland and Holland - original GEHR - CEN 13606 and predecessors - ASTM data set - various national health data sets, e.g. RFA4 (UK), GP dataset (Australia) - GCPR model (US) - the Corbamed (OMG HDTF) interface specifications - CDA, which is not a model of the EHR as such, but is certainly related - open source systems such as Gnumed, Freemed, OSCAR, OIO (which I admit we haven't spent enough time on) - the VHA's Vista system (which we also have not reviewed as deeply as we should) Other models which are no less interesting include the InterMountain Health system which we are looking at at the moment, but many of these are not available for review, as they are not standards and are closed. I'm sure I've missed some important ones here, but one point to remember is: once you go the archetype route (or any similar 2-level approach), many previous models of EHRs are no longer that useful as direct inspiration for the openEHR reference model (they are however very useful for developing archetypes). - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
