Eric Browne wrote:
>It seems to me that openEHR's view of EHR content is still biased >towards the healthcare provider's view of the world, as if a person's >lifelong health status can be represented soley by a linear ( in time) >sequence of "actions" by healthcare providers. It should be remembered >that many of the "events" that change a subject's state >are independent of "intentional acts of health professionals". >In twenty or thirty year's time, we may be mature enough to realize >that the event "person X was made redundant from their employment today" >may have significantly greater effect on X's future health ( or the >health of a close friend/relative ), than "person X was diagnosed with >mumps today". If this is the case, then surely such events should >legitimately be recorded in an EHR? > it may be that our documentation of openEHR does not make it clear enough how richly structured the EHR could be. Everything that is recorded is committed at some date/time by someone, and usually talks about some event, thought, or proposed action, with date/time information attached. However, this time information is not the primary logical structure of the reocrd. The data can be organised and presented according to how an application wishes - e.g. problem / issue "threads" which link symptom observations, diff. diagnoses, test results, diagnosis, care plan modificaitons, etc etc for each problem; - on a time base of problems & issues - current situation - active problems, therapeutic precautions, etc - current proposed actions taken from care plan - this might be a 'care pathway' view In your example, there is nothing in openEHR to stop someone (including the patient) recording that they were fired from work. >I have problems with lumping too many things under observations, without >distinguishing between "state" and "changes to state". Consider the >following:- > >A. The _observation_ "subject weighs Y kilograms" is a state recording. >B. The _observation_ "subject experienced severe pain in lower left abdomen" > is an event recording. An event causes a change of state. > this is recorded using an ENTRY made up of a HISTORY of 1 EVENT with duration xxxx, and data of type STRUCTURE, i.e. a data structure characterising the pain >C. The _action_specification_ "appendectomy" is a process recording. It > similarly causes a change of state. > it depends on whether the procedure has occurred, or whether it is to occur in the future. If in the future, it is an action specification. Note that time in the future is not linear, it is branching, and conditional. >In the above, openEHR places A and B in the observation category. But >from a healthcare perspectve, B is closer to C, than to A. > I'm not sure I udnerstand why this is - can you elaborate? >Someone looking back in time through an EHR might be looking for >seminal events of a certain class. Again, consider a person admitted >to an Itensive Care Unit (ICU) with first degree burns. The current >"Service-Action" view of the world emphasises the care provided at >the ICU, thus de-emphasing the important change_of_state event, namely >the burn event. > I'm not sure why you say this - I would expect that the following would be recorded in the EHR due to this: 1. OBSERVATION Entries characterising the patient initial presenting situation and everything else relevant (shock, breathing, consciousness, bp etc). Every measurement made and committed to th EHR would be an OBSERVATION of the patient. [you might at this point say: why isn;t the burn itself (e.g. "child threw petrol on bonfire and split some on self, experienced 30 seconds of petrol burning on chest, abdoment") being described in the record - it is important? I agree - and there would be nothign to stop this, as long as the information is known. But it might not be, the patient might be unconscious, and be the only one who knows what happened, so I haven't included it here] 2. OBSERVATION Entries indicating the actions that were taken to stabilise the patient, e.g. adrenalin injections, topical treatments etc 3. EVALUATION entries indicating how the situation is characterised, now that it is understood better, and proposing a care plan for it 4. INSTRUCTION Entries indicating specific actions to be taken for the future care of the patient 5. OBSERVATION Entries indicating ongoing progress, execution of actions in 4. and so on etc > The "Service-Action" view of the world portrays the >burn_event as an attribute (observation) of the emergency care act. > actually - this is the HL7 view of the world, not the openEHR one. In openEHR, the patient situation is recorded as an observation, since it is by observation (including interviewing the patient) that this data is obtained. Similarly, if someone can come in and describe the orginal accident (e.g. the child's brother), then this could go in as observations as well. It should be noted that we use the word "observation" to mean "any information coming to the person recording in the record". So everything that happens in the world is a kind of observation, in that, in order to record it, one must receive data about it. Even doing an appendectomy is like this - you record what you observe. > Surely >a more appropriate approach should be to consider the emergency care act >as a consequence of the burn event. This would also allow for subsequent >trauma counselling to be related to the same event, rather than to the >ICU burns treatment _action_specification_. Consequently, I believe that >openEHR should include an _event_ archetype. > I don't see any problem with this at all - I would only say - don't take the Reference Model classes as being the only way to see things. I would encourage everyone to think in terms of the clinical & real world concepts they want, and think about how to build archetypes for them. >A similar argument can be mounted for representing risks in their own >right, rather than mere observations. Unfortunately, today's risks are often >tomorrow's virtues and vice versa. Yet, given today's medical knowledge, >the _observation_ "Person X smokes 50 cigarettes per day" carries >significant value beyond the care event for which the observation is >being recorded. Consequently, I believe there are good grounds for >establishing a _risk_ archetype. > Again i would agree with this. The risk-archetype would in fact assume EVALUATION Entries describing the risk associated with OBSERVATIONs such as the smoking one you mention. Hope this helps. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
