Eric You are into the territory that Computing and Health care have been swimming in for many years - how to model health care - rather than health care recording.
All of these are events - but in the record they will cause recordings that are observations, instructions and evaluations. a. heart attack Might start with the patient observation of chest pain...an obseravtion of ECG... an instruction to order a blood test.. an evaluation of a differential diagnosis.. the observation of the result of the test.. a diagnosis. b. bali bombing Observation .. was in Kuta and hit by debri ... evaluation .. Very distressed and requires counselling .. Instruction - referral to counsellor who is working with such clients. c. job redundancy Observation .. made redundant... evaluation ,, this is a problem that is worth noting in persistent data. ETC... d. rape e. snake-bite f. car accident g. surgical error We are modelling the health record not health care - attempts to model the former have been going on for decades and their work is all over the web. Cheers, Sam > -----Original Message----- > From: Eric Browne [mailto:eric at montagesystems.com.au] > Sent: Thursday, 5 December 2002 10:31 AM > To: aniket Joshi > Cc: sam.heard at bigpond.com; openehr-technical at openehr.org > Subject: Re: Categorising EHR Content > > > Aniket, > > I have refreshed myself on openEHR's clinical model > terminology, but I still think you miss my point. > openEHR has three types of EHR_Entry, namely > OBSERVATION, EVALUATION, INSTRUCTION. > > I am using "event" in the natural language context, > rather than the hijacked Event Summary context. My > "event" refers to a non-care event ( predominantly ). > Such "events" do not fall under any of the 3 EHR_Entry > subclasses. Some examples: > > a. heart attack > b. bali bombing > c. job redundancy > d. rape > e. snake-bite > f. car accident > g. surgical error > > All of these lead to a change of state! I don't see how > any of these could legitimately be classified as any of > OBSERVATION, EVALUATION, INSTRUCTION. Yet, > data describing these "events" should be captured in > the EHR. The data could and should exist independent > of any healthcare action. In some cases, there may not be > any healthcare action following the event. I can conceive > of situations where subjects might wish to record the event > (consider rape) in their EHR, prior to any visit to a > health provider. > > The only way current models appear to deal with this is > by lumping them into either OBSERVATION, or, even as > you suggest, INSTRUCTION (represented by ACTION_SPECIFICATION). > > I think the problem arises because there is no "higher" > level representation of an event ( either definition ). > This is my point. At the high level we should separate > out state, activities/events that change state, risks. > > * state can be categorised as OBSERVATIONS or EVALUATIONS. > * change of state can be categorised as _health_care_actions > (openEHR's INSTRUCTIONS?) or non_health_care_events. > * risks need their own class. > > Clinicians often use OBSERVATIONS and EVALUATIONS to deduce > the event. This is often called diagnosis. A subject might > attend a GP with severe pain and swelling in the hand. The > GP makes some OBSERVATIONS, undertakes a test (issues > an INSTRUCTION) and deduces that an event "funnel-web > spider bite" has occurred. However, sometimes we ( subject, > clinician, other person ) know the event a-priori. > Either way, the event(my definition) is a first class > object in its own right, and should be represented as > such in the EHR. > > Perhaps the data pertaining to a non-care event could be > recorded as "OBSERVATIONS", but some of this data, > may not explicitely be OBSERVATIONS of the subject_of_care. > The data qualifies the event, not the subject_of_care. > > I hope I have explained myself a little more clearly. > > eric > -------------------------------------------------------------------- > > On Wed, 4 Dec 2002, aniket Joshi wrote: > > > Dear Eric and Sam, > > I do agree to these views.When we are trying to > > capture EHR any change in the medical state needs to > > be recorded and classified.But we are trying to > > categorize the formats of recording these changes in > > state. > > A stage lower than the one described. > > The level described below is comparable with Events in > > the EHR and the classification. > > What I meant in the earlier discussion was the > > classification of the data describing the event. > > Those could be classified as different observations > > instructions and actions. > > By your contribution we have a categorisation of the > > different events. > > "The "Service-Action" view of the > > world portrays the burn_event as an attribute > > (observation) of the emergency care act...." > > Yes it should and it would in the prospective view,in > > the retrospective view or a guideline an emergency act > > will be a part of the BURNS SERVICE ACTION. > > What I Mean to say is the BURNS EMERGENCY ACTION > > should comprise of X..Y...Z...a system generated > > unsolicited guideline with the related fields in the > > record has to entered by the HCP. > > Thus the record will be part of the Burns Emergency > > act. > > To summarize I think the idea of categorizing the EHR > > according to instructions,observations and actions and > > the event wise categorization can be agreed upon and > > implemented. > > Comments > > ANIKET > > --- Eric Browne <eric at montagesystems.com.au> wrote: > > > Sam et al, > > > > > > Sometimes it is beneficial to stand back and review > > > the purpose > > > of EHRs, when trying to categorise content. No doubt > > > you have done > > > this far more often than me, but for yet another > > > high level perspective > > > here is my current view. > > > > > > ------------------------ > > > Categorising EHR Content > > > ------------------------ > > > > > > [ in the following discussion, the word "subject" is > > > used. This refers > > > to the person who is the subject of a particular > > > EHR. Information > > > contained in the EHR pertains to that subject. ] > > > > > > In order to be as effective as possible, an EHR > > > should record aspects of: > > > > > > 1. the subject's past, present, expected and > > > desirable state. > > > 2. changes in the subject's state. > > > 3. the events and processes that led to, or might > > > lead to, changes in > > > subject state. > > > 4. risk factors that might influence subject state. > > > > > > In order to do this, we must define the > > > concepts/entities that express > > > state, processes and risks. Sometimes concepts are > > > composed of other > > > concepts. Sometimes concepts are specialisations or > > > generalisations > > > of other concepts. Sometimes concepts are > > > relationships between two or > > > more other concepts. > > > > > > Patient state can be represented by:- > > > * a set of reported symptoms. > > > * a set of measurements, observations, test > > > results. > > > * diagnoses - classification by symptoms into > > > known diseases/conditions. > > > * prognoses - expected symptoms or outcomes. > > > * outcomes from some past, present of future > > > process. > > > * outcomes from some past event. > > > * body parts and accessories ( e.g. pacemaker, > > > organ transplant, > > > walking frame). > > > > > > Events & Processes can be represented by:- > > > * diagnostic tasks. > > > * prognostic tasks. > > > * treatment tasks. > > > * medication prescriptions. > > > * tests. > > > * the relationships with participants involved in > > > the processes. > > > * accidents or events that sigificantly altered or > > > might alter > > > the subject's state. > > > > > > Risk factors can be:- > > > * environmental (e.g. adjacent to lead smelter). > > > * behavioural (e.g. smoking). > > > * genetic (e.g. familial history of cancer). > > > * allergic reactions that have occured to this > > > subject. > > > > > > 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? > > > > > > 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. > > > C. The _action_specification_ "appendectomy" is a > > > process recording. It > > > similarly causes a change of state. > > > > > > 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. > > > > > > 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. The "Service-Action" view of the > > > world portrays the > > > burn_event as an attribute (observation) of the > > > emergency care act. 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. > > > > > > 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. > > > > > -------------------------------------------------------------------- > > > regards, > > > eric > > > > > > > > -------------------------------------------------------------------- > > > > > > On Wed, 4 Dec 2002, Sam Heard wrote: > > > > > > > > > > > Aniket > > > > > > > > Thanks for that. > > > > Thanks for your thoughts. > > > > > > > > > There are finite orders in the Medical > > > Terminology > > > > > which can be classifed according to the > > > department and > > > > > coded. > > > > > Effort such as CPT(Common procedural > > > terminology) can > > > > > be extended and continued to encompass all such > > > > > 'action specifications'. > > > > > Thus the medical record can be structured > > > broadly into > > > > > a.Enquiry specifications(history) > > > > > > > > We call these observations (as per Rector) - the > > > subject is the source. > > > > > > > > > b.Examination specifications(clinical > > > examination) > > > > > > > > We also call these observations - the clinician is > > > the source. > > > > > > > > It is quite difficult to separate these more > > > conclusively - a patient may > > > > say they are constipated and have not used their > > > bowels for 5 days - in a > > > > nursing home a care attendant might notice that > > > the patient has not used > > > > their bowels for 5 days. These are no different > > > except in source and we have > > > > found it helpful to use the same information > > > component. > > > > > === message truncated === > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
