The concept of contribution
aniket Joshi wrote: >Dear Sir, >The concept of "contribution" is definitely >'essential' for the functioninig of an efficient EHR model. >For all practical purposes the memory of the patient >and the HCP is in term of "events". >Each of these "events" have a distinct title for >eg.Appendicectomy and have a number of examinations inside them. >Each examination has a versioned_transaction as a record. >Thus the event is a cluster of examinations and >contribution can act as a cluster of >versioned_transactions with a title. > it seems to me this use of the word "event" is more what I would call an "episode", i.e. a period of time during which a number of related things happen (e.g. admission, examination, operation, review, discharge). The defining aspect of "contribution" we are saying is that it is the unit of change to the EHR - it is due to a single "clinical session", which might be - a patient contact - a set of test results - the acquisition and merging of an EHR extract or message >During retrieval the Health care provider will have to >select a contribution after which only the related >Versioned_transactions will have to be retrieved. >Will this reduce the speed? >DR ANIKET JOSHI > not completely clear on the querying scenario you are proposing here. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The concept of contribution [long]
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 cult
Emailing: _0125.htm
Tony Grivell wrote: > I think that's a reasonable suggestion - especially since different > people interpret these (and related) terms differently. I've picked > out a couple of 'definitions' in the form that pathologists use (and > in my experience this is a group who are precise and pedantic in a > very professional way! - and they are the generators of much of the > quantitative data in an EHR). In fact, they have come from a draft > European standard from CEN/TC and are consistent with ISO and other > international bodies. (Taken from R. Haeckel (Ed.) "Evaluation > Methods in Laboratory Medicine") Tony, can you give me the full reference to this? I'll quote it in the Reference Model > "ACCURACY is the closeness of the agreement between the result of a > measurement and a true value of the measurand". I.e it depends on > knowledge of the TRUE value of the thing being measured, as during > analyser calibration, when a consistent BIAS might be noted. It 'is > usually expressed numerically by statistical measures of the inverse > concept, INACCURACY of measurement', which is defined as "discrepancy > between the result of a measurement and the true value of a measurand" > - and which 'is usually expressed numerically as the error of > measurement'. 'Inaccuracy, when applied to sets of results, describes > a combination of random error of measurement and the systematic error > of measurement.' So this means that "+/-5%" is a statistically-based measure of the inaccuracy of the instrument or method being used. It does not make any statement about the individual measured value with respect to the "true" value - only that statistically, it is known to be within the 10% wide band centred on the true value. > "PRECISION of a measurement is the closeness of agreement between > independent results of measurement obtained by a measurement procedure > under prescribed conditions". I.e. the variation obtained with > repeated measurements on a single specimen. Precision thus 'depends > only on the distribution of random errors of measurement. It is > usually expressed numerically by statistical measures of imprecision > of measurements'. "IMPRECISION is the dispersion of independent > results of measurements obtained by a measurement procedure under > specified conditions". 'It is usually expressed numerically as the > repeatability standard deviation or reproducibility standard deviation > of the results of measurement.' When applied to sets of results, > imprecision 'depends solely on the dispersion of random error of > measurement and does not relate to the true value of the measureable > quantity'. a) so what about the "definition" of precision as significant places in a number, i.e. the level of preciseness to which a numerical result is reported - which is logically related to the definition above, since there is no point reporting to a higher degree of precision than actually available in the real-world measuring process... b) the above definition would imply that we should report a standard-deviation of a notional population of meansurements of the same actual value c) should there be a merged definition of these concepts, as per this suggestion in HL7: (quoting Gunther Schadow from CQ/MnM lists in HL7) The NIST guide for uncertainty in measurements says that the traditional notions of accuracy vs. precision should be superceded by the one concept of uncertainty. So, any given measurement you take is really a probability distribution over the measurement domain. The probability distribution is typically described parametrically. The NIST guide goes into quite specifics about that and I have to say that it went a little bit past my memory. But one of the ways they do specify their uncertainty is by giving the mean and a standard deviation. That's often assuming that your distribution is normal, which it often is due to the central limit theorem. But if it isn't, you need to know what your distribution type and its parameters are. In HL7 v3 we have a data type called Parametric Probability Distribution, which is a generic type extension that works with any base data type. In most cases we will have a PPD. The PPD ends up having the properties: mean value unit distribution type code standard deviation The distribution type code can distinguish normal, gamma, beta, X^2, etc. The table of distribution types also summarizes how the parameters mu and sigma relate to the specific parameters that are usually used for each distribution type. During the design of this we thought we would better use the specific parameters for each distribution type, but those turned out to be all deriveable from mu and sigma. The advantage of sending mean and standard deviation consistently is that even if a receiver does not understand the distribution type, he will get a pretty good idea about the measurement from just looking at mu and sigma. I wo
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
