An ACTION or INSTRUCTION referencing an AGEN, is it possible?

Hi Athanasios,

I don’t want to create clinical modellers from developers, neither I can teach clinicians on clinical modelling, but I can teach information modelling in the future (as you mention below).

I have students that are not developers (physicians, nurses and other health professionals), and for them it’s very difficult to start modelling with archetypes and the information model.

The information model is good and clear, the OBSERVATION vs EVALUATION debate is not the problem, but the problem is how to classify concepts from reality into those classes.

As you mention, a lot of experience is needed to do it right. And I think current modellers have a lot of experience and that experience can be shared in a scalable way. Now this is done by specific questions on the lists or discussions on the CKM (this way doesn’t scale and the same discussions are repeated over and over again). I think there are a lot of patterns and criteria that can be used as guidelines for those who just started in clinical modelling, and could be defined one time in one place.

Guidelines are not lookup tables or a cook-book, they are a “thinking support”. Call it guidelines or success stories, the idea is the same: share knowledge about how to classify (using the IM) and model clinical concepts, which classification is not so clear (I propose to start with DEMOGRAPHIC concepts that are not PERSON but should be recorded into the EHR).

Guides or a patterns are not hard rules, but if there is a hard rule hidden somewhere, it should be detected and added to the specs, this is exactly what I tried to detect on these messages.

Sorry if I’m not making myself clear, I believe some of my messages are misunderstood by my poor english skills :-/

This became a very rich and interesting conversation, it is being very good to be learning so much with you all.

So EVALUATIONS are NOT limited to opinions or assessments, although that is a common misunderstanding.

I have to disagree, the paper “An Ontology-based Model of Clinical Information” says:

“In summary, the Opinion category is distinguished from the Observation category by representing inferences from evidence, rather than representing the evidence. Two investigators can form different interpretations of the same set of observations, but the observations themselves remain an objective picture of some aspect of the patient’s situation, within the limits of the observational method itself. Similarly, two investigators can formulate different goals and plans based on the same observations, and even the same diagnosis.”

And the Information Model document (p57-58), which is based on the paper “An Ontology-based Model of Clinical Information”, states:

The name Evaluation has been present in openEHR for some years, and is retained for reasons of continuity.”

– The first in which we record now or at a specific point in time or averages usage over an identified period of time, and which is best represented in an OBSERVATION so that repeated and comparable records can be made over time – effectively a concrete smoking diary of actual smoking activity, whether now, on a certain day, or an actual average over the past 10 years.
– Secondly the data that fits more with an EVALUATION – for example, data that we will only ever need to record once and should be persisted, such as ‘Date commenced tobacco use’, or that we want recorded in one place only and choose to update over time with versioning of COMPOSITIONS, such as cumulative consumption in pack years etc.

I now understand your concerns about the separation of models, but an Observation CAN be data that we will only ever need to record once and should be persisted, such as mentioned in the Information Model document, for instance Family History includes “actual events / conditions in family members are recorded as Observations (e.g. father died of MI at 62)”. Also, as Heather wisely said in her paper openEHR - the World’s Record: “The archetypes contain a maximum data set about each clinical concept”.

I would have to disagree here - while a summary is not an assessment like diagnosis, it is an opinion, or ‘evaluation’ by the health professional in the sense of what he/she chooses to include as a summary of the patient situation, as understood by the current professional, for consumption by other professionals so that further care can continue. It is not an observation of anything on/from the patient - it is a creation from the mind of the professional based on previous observations, documenting what he thinks is important or otherwise for ongoing care. There is no primary ‘observation’ activity going on here.

I wasn´t thinking this way, but from this point of view, now I totally agree with you in the sense that the health professional can chooses what to include as a summary of the patient situation, so each health professional can develop a summary with different items.

But the problem is that data to be included in the Evaluation summary can not be chosen from an Observation and serve as substratum by the health professional. The data is already defined within the archetype and some of them aren’t within Observation (e.g. Tobacco use - Date commenced). Also, most of Evaluation summaries have no space to record different interpretations of the same set of Observations. Can it still be considered an Evaluation summary?

I agree with Ian’s solution of merging the archetypes into a single Observation archetype, to be used for different scenarios with slightly different templating.

In my opinion the relevance to correctly describe the classes goes beyond the query. It begins when someone decides to choose the archetypes to be used in an EHR. It may generate mistakes and lead to error and disillusions.

Cheers

Hi, you all

It’s so exciting to be part of this excepcional moment of our community, showing that, despite our different points of views, we’re enlarging our knowledge. But, as Thomas Beale once pointed out that blackberry users were unusual email responders, same apllies to iPhone ones, interface is not made for emails, but to twitter.
In this case i think you all have to wait to my personal thoughts on this matterhorn tomorrow…

Jussara Rotzsch
OpenEHR Foundation,Director

Hi Gustavo,

There are situations where it is helpful to use ACTIONS to record the
process of an OBSERVATION (or group of Observations) e.g to monitor
the progress of a lab test order or a request to perform regular Vital
Signs monitoring, This will become much more common as we move towards
care pathways and distributed workflow but in general I agree that in
most cases we do not need or want to record an ACTION for every
OBSERVATION.

I agree with Pablo that it would be good to document why and how we
adopt particular approaches but we are all learning in this situation
and as you have discovered with Tobacco use, we are all still
unearthing a mixture of use cases that need to be represented and
often break or at least challenge current classification guidance. I
do like the idea of explaining "how we did it" rather than presenting
our experiences as guidance. I am sure best practice and guidance will
emerge but we still have some way to go.

Ian

Hi Grahame,

I agree that all real-world Observations contain some element of human
interpretation. I think this is well understood and that the break
point is whether that interpretation applies to the test or to the
patient as a whole, when in openEHR terms it becomes an Evaluation,
which equates pretty closely to the AORTIS definition of synthesis.

I think clinical recording practice recognises the difference between
an "ECG diagnosis of atiral fibrillation" as a human or computer
interpretation of an ECG waveform as against a "Diagnosis of atrial
fibrillation' applied to the patient. Even where ECG diagnosis is
regarded as the Gold Standard, I think we are still some way off an
ECG machine being empowered to update a patient's problem list.
Similarly a 'pathological diagnosis' of Lung cancer does not have the
same status in a clinical record, or in practice, as "This patient has
Lung Cancer".

It is interesting that with the exception of 'summaries', there are
virtually no new EVALUATION archetypes in any of the CKM repositories
or in the local systems I have worked with. I am beginning to think
that Summaries is possibly one of the few grey areas left.

Any insights from FHIR?

Ian

Everything documented in an EHR is based on human interpretation.
Therefor human interpretation is not a discriminator when we want to define the specialisations of an Entry.
And neither is the fact whether something is located in time.
An neither is the fact whether it applies to the patient as a whole or part of it.

It is my conclusion that in openEHR for sometime now the wrong definitions are used.
And thereby archetypes get the wrong semantic annotations.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M: +31 620347088
E: gerard.freriks@EN13606.org

W: http:www.en13606.org

Gerard Freriks
+31 620347088
gfrer@luna.nl

Hi Gerard,

The last time I look at your alternative definitions, they seemed
pretty close to the original openEHR ones.

EVALUATION:
class in the Target Reference Model
that can be used for the documentation about an inferred process in
the patient system using observations, expertise and knowledge,
or about plans with,
or risk assessments about, the Patient system
Observe: Evaluations are based on observations and can lead to instructions.

How would you categorise "Tobacco Use", Evaluation, Observation or both?

How would you model an "ECG diagnosis of atrial fibrillation"? Is that
about the patient system or the

I am pretty sure that whatever definitions are used they will fail to
apply correctly in all circumstances, or lead to That has been the
history of all clinical modelling efforts up until now and I don't see
why anything should change. The harder we try to model things
'correctly' from an ontological perspective, the more we fragmenting
the models into components that are hard to understand and harder to
implement and ask clinicians to understand whatever we throw at them.

Ian

Hello!
Just a few cents, as Gerard wrote:

> Everything documented in an EHR is based on human interpretation.
A raw, non-validated, blood glucose value is not based on human interpretation. It comes out of a machine.
It is a requirement for EHRs to support the clinical validation process.
I therefore conclude that some EHRs need to store information that is not based on human interpretation.

Hope this helps, greetings from Vienna,

Stefan Sauermann

Program Director
Biomedical Engineering Sciences (Master)

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
P: +43 1 333 40 77 - 988
M: +43 664 6192555
E: stefan.sauermann@technikum-wien.at

I: www.technikum-wien.at/mbe
I: www.technikum-wien.at/ibmt
I: www.healthy-interoperability.at

Hi Everyone,

I would go even furhter. In many observation procedures effort is made to reduce the effect of human interference to a level where the fact that, as Gerard says, what’s documented always goes through a human mind is insignificant. My interpretation of the openEHR OBSERVATION-EVALUATION distinction is just that, if the human interpretation is of significance or not. So even if the blood glucose is checked, validated, etc. by lab staff I would still argue that that human interpretation is (more or less) insignificant to the (later stage) interpretation of the blood glucose result.

/Daniel

Stefan,

I agree.

For me the EHR contains data and information that is placed there because of an author/healthcare provider.
In my ‘book’ all data and information must be there because of the execution of an act by a human. There is a strong legal requirement that always a human can be held accountable for what is in the EHR or is not in the EHR.
The prime function of the EHR is to be the container where the healthcare provider as author documents the healthcare provision process.

Next to the EHR data and information, there is a need for EHR-systems to hold data and information that has been received and is waiting to be inserted by the author/healthcare provider.
In other words I see the need for an IN-box and an OUT-box where data and information sits in limbo until it is processed by the author/healthcare provider.
Data and information in these boxes is NOT part of the EHR proper, but connected to, or associated with, it.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Dear colleagues,

What is wrong with the definitions we use in the EN13606 Association?

Paraphrasing:
Observation: is about phenomena generated by states in the patient system and that are observed using the faculties of any human (seeing, smelling, etc)
Evaluation: is about Inferences about any process in the patient system
Instruction: is about Plans to change a state or process in the patient system
Action: is about the planned execution of a protocol or an unplanned event (‘Act of God’) that influences a state or process in the patient system

A patient system is:

  • any component of the body
  • the body/person as a whole
  • its environment ( family, coworkers, physical environment, etc.)
  • a set of processes that can be inferred
  • a set of phenomena, generated by processes, that can be observed.

Some of these specialisations of the Entry class involve others than the patient and the author: other persons, devices, services.
All are agents, actors, that need to be documented when they play a role in the healthcare provision process as documented in any EHR.
I consider each of these types of actors as kind of resources that contributed or will contribute data/information to the EHR.
Each of these resources will have its specific specialisation of a Cluster Model pattern that allows the recording of relevant specific data about the resource.
There will be Resource Models (Cluster models) for persons, organisations, devices, various services.

Gerard Freriks
+31 620347088
gfrer@luna.nl

In reality each observation is performed following an explicit or implicit protocol.
That what is taught and trained in Medical School.

Actions execute those implicit or explicit protocols. Unless they are unplanned (e.g. Lightning, other ‘Acts of God’, car accidents, etc.)
Observations store in the EHR the result of the Action as subjectively perceived by the author/healthcare provider using its senses.
By definition the Observation is always coupled with an Action. Always something must happen in order to produce a result that can be observed.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Hi Gerard

I don’t have a problem with the definitions. I am interested in how you would apply these to the ECG diagnosis and tobacco use examples I gave before. I am sure we can always apply better definitions but I have found that this does not necessary resolve these sort of issues. The more abstract the definition, the more open to interpretation, the more specific the definition the more edge cases break the rules or force us into creating unnatural constructs solely to meet the definitions.

Ian

Dr Ian McNicoll
Clinical modelling consultant Ocean Informatics
Mobile +44 (0) 775 209 7859
Skype imcnicoll

Ian,

Thanks.

‘ECG diagnosis’: You mean an interpretation of the ECG like:‘atrium fibrillation’ or ‘pattern conforms to infarction in the left lower cardiac artery’?
In ‘my book’ the first is an Observation provided by a an Action that defined the device/service that produced it.
In ‘my book’ the second is an Evaluation of an Observed pattern as provided by a Action that defined the device/service that produced it.
Both Observation and Evaluation need to be confirmed/committed by the author of either one.

‘Tobacco use’
For example the amount of cigarettes used per day is clearly is an Observation (a state at point in time) because it is not about the process inside the patient system it can be seen, heard, smelled, etc..
For example the addiction to nicotine is a process (a condition) inside the patient system and therefor an Evaluation. The process can not bee seen, smelled, heard. Only inferred and phenomena that are produced because of the addiction can be observed.

Are our definitions helping to resolve these complex things?

Gerard Freriks
+31 620347088
gfrer@luna.nl

Hi Ian,

In an other e-mail I have explained how ‘problems’ like: ‘ECG Diagnosis’ and ‘Tobacco use’ can be modeled.

[Have a look at the url and download this e-mail as PDF including some pictures that were to big
https://www.yousendit.com/download/QlVqK0d0WkJ3TGhMWE1UQw ]

Modeling archetypes on one hand have to take on board ‘structures’ (EHR-Extract, Database schema) since they constrain these structures.
On the other hand there is the world of coding systems and the world of ontologies.
We have to take on board the worlds of coding systems and ontologies, as well.
That is to say as long as we agree that we are after semantic interoperability.

Your belief that ‘definitions will fail in all circumstances’ is strange.
In mathematics definitions play a key role and nobody will agree with you.
A possible reposte by you might be: ‘Health Informatics is not science or mathematics’.
My answer would be: look at the sciences of logic and semantics and language.
When one is using wrong definitions I can understand your belief.

In any case we need proper definitions for the members of a coherent set of concepts.
Concepts that deal, in this particular case, with parts of any documentation process executed by any author inside or outside healthcare
Each of these concepts need a definition that is exact and discriminates it from other members of the set.
These definitions must be such that we can use them with the minimal risk of misinterpretation.

The next set of definitions below is a serious attempt by the EN13606 Association.
I expect there will be improvements in the near future.
The prime discriminator is the relationship with the Patient System.

The basic assumption is that any patient system has processes that can be inferred only.
Only consequences of these processes can be observed as a phenomenon by humans (and machines).
For example: We can not see the process of diabetes. We see the results of it, the consequences: the elevated blood sugar level when we measure it using a protocol.
An other and implicit assumption is that what humans do is: use their faculties to interpret phenomena, think and infer and generate new phenomena we call: speech, writing, etc.
We as many living organisms: see, think and act.

Some of these things are depicted below.
The set of coherent definitions are part of the Documentation Process, as one of the 5 realities we all have to deal with in semantic interoperability.
The Patient System is also part of these 5 realities.

Realities involved in EHR documentation

In the context of the EHR and documentation of data and information several autonomous realities exist. Each of these need its own ontology, set of models, terms and rules.

Five realities

  1. Patient System Biological/life processes (normal, abnormal/disease) and constituting elements
    that what really is going on inside the patient system and can only be inferred
  2. Healthcare Delivery process
    where the patient and the healthcare provider/author interact
  3. that what the patient produces as observable phenomena (objective, subjective)
  4. that what the healthcare provider subjectively perceives, interprets, inferences about what is going on inside the patient system
  5. that what is actually done to the patient and produces changes inside the patient system1. Documentation process
  6. that what gets documented.
  7. that what is interpreted when read as documented1. Codes used to document
    Describe how processes and constituting elements in the patient system are named/coded. These words/codes relate to term/concepts used in the four other domains.
  8. Archetypes/Templates
    Archetypes are used to document and must relate to coding systems and ontologies.

Each of these ‘Realities’ will have its own set of terms/codes and ontology that describe it fully.
Semantic interoperability is possible when all five Reality Domains are in place