Sam, OK. By extrapolation, then, any documentation of a healthcare event or non-healthcare event that has occurred in the past, is recorded as an observation? Any healthcare event that has not yet occurred, but envisaged, is recorded as an instruction?
When a patient is discharged from hospital, all actions that were taken on the patient are recorded as observations. e.g. appendectomy ? This means the semantic knowledge of state vs. change_of_state is buried pretty deep in the record. eric -------------------------------------------------------------------- On Fri, 6 Dec 2002, Sam Heard wrote: > > 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 > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
