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

Clinical (archive)
21

Hi Ian,

From: Ian.McNicoll@oceaninformatics.com
Date: Mon, 18 Jun 2012 14:44:58 +0100
Subject: Re: An ACTION or INSTRUCTION referencing an AGEN, is it possible?
To: openehr-technical@lists.openehr.org
CC: openehr-clinical@lists.openehr.org

Hi Pablo,

The EHR-CLUSTER archetype were created for some specific use cases,
where it is necessary to record demographic information within the EHR
itself, because the demographic
entity is not supported by the external Demographics service, for
technical or legal reasons e.g 3rd party carers or people reporting an
incident or perhaps laboratory contact details.

I think this kind of things (and also the “rules” or “patterns” I tried to draft in previous emails) should be part of some “modelling guideline”, because it’s difficult to new modellers to learn about the EHR and DEMOGRAPHIC models and then model all concepts on the EHR side. I’m not a modeller, but the openEHR course I give is “creating” new clinical modellers, and with clear rules we can encourage them to create and improve archetypes (and with fuzzy rules we do all the contrary).

I know Heather tried to draft some ideas on clinical modelling and quality on the wiki and this kind of things could help to it. You know, I’m a techie and I don’t work well with fuzzy things: 0/1, rules and patterns are my friends :smiley:

They were developed completely separately from the formal DEMOGRAPHICS
archetypes so it is not surprising that they have somewhat different
structures. I agree that it would be preferable to align some of
these with their Demographic equivalents but I am not sure that gives
much additional benefit to implementers..

I think it’s all a matter of consistency, e.g. “The purpose of the [DEMOGRAPHIC] model is as a specification of a demographic service, either standalone, or a “wrapper” service for an existing system such as a patient master index (PMI).” (Demographic Model page 9).
It’s clear that for PERSON we will have services that handles identities, but it’s not so clear for other demographic parties like AGENT, GROUP or ORGANISATION (each one has an identity). So, if a demographic service implementation can handle a PERSON search by it’s identity attributes, I expect the same behabiour for the other parties.

If this is not the expected behaviour of the DEMOGRAPHIC services, then there are two? options:

  1. the DEMOGRAPHIC model should not include other parties than PERSON and ROLE
  2. the DEMOGRAPHIC services should add support to operations based on other parties than only on PERSON (GROUP, AGENT, ORGANISATION).

Maybe Thomas can add light on this last statement.

Our approach so far has been to model devices as Clusters within Entry
archetypes. I have done this both for measuring devices and for other
devices such as cannulae, catheters and drains. In any cases the
device may have a dual role.

IMO, this is exactly the kind of things that should be included into a modelling guide, and a guide could be a very helpful tool to train new modellers. (There are people already asking for this and I can’t help them because I’m a techie, we need clinical partners!)

As Heath has said, the problem with modelling the device as the
clinical author is that it is the instance of the device and not the
class device that needs to be the author e.g Nonen pulse oximetry
1123-456-769, rather than just Nonen Pulse oximeter. T

Do you mean participation instead of author?

This means creating a PARTY entry for every single actual device used
in the clinical setting. There may be some added value in having a
Device registry to track the physical assets but using openEHR
Demographics to model this feels like a significant overhead.

I understand that in some cases there’s a need to record the device class (type=xxx) and in other cases the device instance is needed (id=xxx), e.g. an hemodialysis session record should include the dializer id (some number), I think this has something to do with the filter used by each patient (I worked on hemodialysis a long time ago).

BTW, some of the attributes of a device should be previously known, I mean you don’t enter each data everytime, just select from a list what device do you use, and that selection should(?) consume a DEMOGRAPHIC services to get all that information. Some values could be added to the record, other values just stay in the demographic records. So I think the “significant overhead” it’s a matter of software implementation. Of course I could be really wrong.

The device may have other use-specific attributes that need to be
captured such as Entry site, location, exposed length, which
definitely need to be modelled in the EHR in a specific Composition.

So, although you could have a device as the clinical author, I think
you will end up having a lot of information that needs to be captured
in the EHR, against specific Entries. There is a case for a separate
devices asset registry but the openEHR Demographics service feels like
the wrong place for this.

Here is the point of consistency I mentioned before, if we want to model AGENTS, GROIPS and ORGANISATIONS on the demographic model, the demographic services should support those classes too. But maybe is not the place for all kind of “AGENTs”, just for those instances that matter to the clinical record.
Talking about guides, what things we have to put into demographic repositories behind the services could be helpful to an implementation guide :smiley:

What do you think?

Kind regards,
Pablo.

22

Dear colleagues,

A SUMMARY in the terms of the definitions as defined in the EN13606 Association document is:
an ad-hoc collection of subjectively selected facts, thoughts, and plans.

In our ‘book’ it is therefor a SECTION archetype where Observations, Evaluations, Instructions and Actions are (re-)used to provide the details.

Gerard Freriks
+31 620347088
gfrer@luna.nl

23

Hi Heather,

As you know we have both gone round in circles on this, and I have
certainly changed my opinion rather more often than I prefer to admit.
As you know I am uncomfortable about trying to express something as
basic as 'Smoking History' in two different archetype classes.

Leaving aside the complexity of the way that people record smoking
details inside the archetype, I think we recognised 4 differing
use-cases

1. A pro-active smoking log where the user documents their daily smoking habit.

2. Where smoking history (implying life-long use ) is collected as
part of a history, perhaps in GP consultation or first hospital appt,
within the context of a some sort of Encounter i.e an event
composition.

3. A variation on (2) where the patient is asked about their smoking
history with respect to a particular event e.g. "Before you knew you
were pregnant" "Since you found out you needed an operation".
Again collected within the context of an Encounter or other event composition.

4. The need to maintain some sort of 'Current smoking status' /
longitudinal 'summary' view both to assist quick human understanding
and as the 'source of truth' for decision support. This needs to be a
persistent Composition (or part of a persistent Composition) and might
be entered directly, or more likely updated via (2 or 3).

There are a number of archetypes where, strictly speaking, we munge
content that strictly speaking belongs in 2 different classes -
Adverse Reaction is a good example and I think Tobacco use is one
where we could safely merge things like tobacco status and pack days
into a single Observation archetype, to be used for scenarios 1-4
above, with slightly different templating.

Ian

24

Hello pablo and everyone

I am watching this discussion with interest and i thought i might say this:

After Ian posting that paper yesterday i think that it becomes clear that slowly the clinical world (or at least, the subset that is interested in this kind of activities) seems to be tending towards the information modelling discipline.

It is definitely easier for a clinician to pick up this skill, rather than turning a developer into a clinician.

Various approaches are popping up in papers (such as mind maps for example) and you can almost trace parallel lines with progress in modelling that ultimately led to UML (flow charts, data flow diagrams, general information modelling principles such as trying to break a domain down into "things", "roles", "actions" etc...).

I am not aware of the breadth of the course you are delivering but my suggestion (if you are not already doing it) would be to provide to some extent at least an introduction to object oriented modelling not with a view to "creating software" but just to describe how a set of concepts with distinct attributes relate to one another.

This puts into perspective the whole modelling process (in general) and openEHR (in particular).

Patterns and guidelines are definitely useful, but i have a feeling that this whole thing is not about just expressing a domain through openEHR provided data-structures. I don't think this is a look-up table process (yet).

It requires a lot of data collection from the field (evidence), it requires (some :slight_smile: ) thinking and a lot of experience.

Therefore, instead of having patterns and guidelines we could simply have examples that worked ("success stories" in a way), complete with their requirements, specifications, evidence (data) and prior knowledge that led to their development. Expressed in an accessible narrative (for a mixed audience). Perhaps there is already material for some of these (?).

I don't think that a "cook-book" style approach would work....i may be wrong of course.

All the best
Athanasios Anastasiou

25

Hi Gustavo,

I’m trying to catch on this interesting discussion.

26

Hi Jussara,

I’ve been struggling with this example from some time now and it would be nice to have a clinical oppinion :slight_smile:

On imaging tests, the result of the test is not the images itself, but the imaging report/radiology report.
The report is an EVALUATION (there is interpretation here) of an image and the image could be seen as an OBSERVATION.

Should be the report considered as an OBSERVATION or as an EVALUATION?

Another example is on complex lab tests. Last year I’ve worked with software providers of a private lab and they told me that for some tests they manually interpret the results to detect problems and fire alerts. They do not have a CDSS to make an automatic process, so the “rules” where executed by lab profesionals, and the result of they interpretation was part of the study result.

I know this is weird but reality is weird :smiley:

27

All observations are the result of evaluations of generated data. I
think the difference
is whether the evaluation concerns the data itself, or the
significance of the data
to the patient's treatment.

The problem I have with Evautation vs Observation is that most real
world processes
seamlessly mix both - diagnostic tests are a classic example - some
contain almost
wholly observation, and some contain both, and a few are nearly all evaluation.

Grahame

28

Hi Sam,

29

Hi Gustavo,

I agree with you and Jussara, and it’s a good definition to use at “modelling time”, but the problem behind this is at “modelling time” you don’t have the contents.

A definition used for modelling coudn’t relly on the contents because you can’t control what a clinician will record on the system at “execution time”. And a system can’t say “hey! do not make any interpretation of this information to record as an OBSERVATION”.

Another way to look at the definition of the ENTRY subclasses is not as a “hard classification”, but as a guideline to modelling with quality.

What do you think?

30

All that is documented by an author is subjective and evaluated by the author.
So we need to have a better discriminator.

ERS proposed to have as discriminator the relation with, the effect on, the patient system.
In short:
Observation: the documentation by the author of a state in the Patient System by means of using its faculties for observation.
EValuation: the documentation by the author of an inference on a process in the Patient System
Instruction: the documentation by the author of plans that have the intention to change the Patient System
Action: the documentation by the author of events that have the intention to change either the state or process in the Patient System

It think that when these definitions are adopted we all know what the function of each of these specialisations of the ENTRY class are.

Who has a better way to define and discriminate these ENTRY specialisations.

Gerard Freriks
+31 620347088
gfrer@luna.nl

31

The definition of ENTRY specialisations are essential when data is to be interpreted and processed by clinical Decision Support Systems.
The semantic meaning must be clear for 100%.

Gerard Freriks
+31 620347088
gfrer@luna.nl

32

to be clearer, the intention is that an ‘agent’ is any of this things ‘acting’ in some autonomous way, rather than being ‘used’ passively by a human or other user. A syringe is in the latter category; at least some ICU monitoring machines can be considered in the former category. But in the end, the actions performed and information generated by any device or robot have to have been sanctioned in advance by some human / group, and are implicitly sanctioned all the time by that responsible agent. So the idea of who is ultimately the ‘responsible healthcare professional’ doesn’t disappear, even if the authorship of some data items in the EHR now appear to be software or other such ‘agents’.

  • thomas
33

On Archetypes and Ontologies…

Ian often says: ‘it doesn’t really matter in the end, what matters is whether you know how to query’. From a practical perspective, this is correct, and it is what we should be focussed on, not being over-theoretical about the ontological side of things.

So the basic rule is: no matter what RM class you base your archetype on, once you have made your choice, and built your archetype, then it is 100% clear how to query the data, because the path set is known.

The real ontological job isn’t to obsess about the reference model class, it is to connect the archetype into a purpose built ontology of clinical information types, built using e.g. Snomed CT technology, and/or in OBO/OWL form. These latter resource types are flexible, in particular, multi-hierarchical, and the archetype can be classified in multiple detailed ways - as a summary, as an ‘observation’ of some kind (if that indeed makes sense), and as any of the content types Ian referred to yesterday, and in any number of clinical ways. The utility of ‘indexing’ archetypes via proper ontology is that we can then easily discover within a population of (possibly thousands of) archetypes, where the data points for any given thing are, and how to construct queries for them.

As Ian has also often said, noone is going to query for Observations and Evaluations, based on the RM classes and nothing more. With proper ontological indexing in place, this is undoubtedly true.

I suggest that this approach is the real future of ontological thinking around archetypes; the Observation/Evaluation question is interesting for a coffee break debate, but its only real importance is: which one has the appropriate data structure?

So what we should be concentrating on is a) working with ontologists on building the ‘indexing’ ontology/ies and b) wasting as little time as possible on building good quality clinical models.

  • thomas
34

If we continue to use the word ‘Evaluation’ in all its possible senses in English, this comment is undoubtedly true. But its meaning in openEHR is narrower than that - it is a ‘clinical opinion about the subject based on previously collected evidence’. So although a doctor manually ‘observing’ e.g. mitral regurgitation is making an ‘evaluation’ in some low-level cognitive sense, she isn’t forming a clinical opinion on the patient, she is just performing an observation with an imperfect instrument (her stethoscope, ears, knowledge of what sounds to look for) which any competent physician could replicate.

If you don’t like the name ‘Evaluation’ we used in openEHR, think of it as ‘clinical opinion’ or ‘clinical assessment’ of the subject of care.

We can always have the debate about whether there is any reality other than our own ‘subjective’ experiences, i.e. that says that ‘everything is an opinion’. Philosophically speaking this is true, but not practically interesting. For normal life, the ‘opinion’ that a trained doctor has that there is mitral regurgitation happening simply doesn’t have the same status as the later diagnosis of ‘mitral valve prolapse’, which is a (potentially) treatable condition.

Having said that, some of Grahame’s favourite lab test result + interpretation examples may really be examples of Observation + Evaluation. It depends heavily on whether the pathologist has the patient data relevant to interpreting the result for that patient, if so, then it probably is a real Evaluation (in the openEHR sense); if not, then all he is doing is reporting the ‘meaning’ of the result for a ‘normal person’, i.e. a textbook interpretation. In all such cases, I would expect the patient’s physician to make the ‘real interpretation’, so that such results should be recorded as Observations.

  • thomas
35

So if that is the case, why don't stick with a generic Entry and use
the ontology described on your paper (T. Beale et al. / An
Ontology-based Model of Clinical Information) to clearly describe
(bind) the root node of an archetype?

If you use classes and an ontology with meaning you have the potential
to assign snomed codes which could be semantically wrong (e.g. a
Snomed 'finding' code on a wrong RM class)

36

Hi Diego,

I think the point is that for most of the models there is a pretty
clear distinction between what is an Observation and what is an
Evaluation, and in the majority of cases the 'ontological'
classification matches up with the structural class. There are a few
grey areas where the congruence of the class and the ontology is more
tricky or strictly speaking might be properly expressed as 2 classes -
tobacco usage is a good example. The problem, IMO, is that clinical
information is so complex and the requirements so varied that whatever
ontological or structural approach we choose, that there will be grey
areas like this, and , for the most part, they do not really matter.

I have sympathy with your suggestion of using a generic ENTRY and an
ontological label to classify it as an Evaluation but it is really not
that important in system use. What does it matter, in real use,
whether we label something as an Evaluation with a class name or with
some sort of ontological label, rather than a generic ENTRY? Nothing
happens because something is labelled as Evaluation. I never query
for is_an evaluation - I query on is_a problem or is_a goal.

Ian

37

Hi Diego,

I think we have found that the idea of protocol (method, metadata etc) applies to virtually every clinical data collection. I think Evaluation is the catch all for the reason you have identified.

The history of this is:

Care Entry - data + protocol

Requirement to deal with serial observations, interval measurements etc.

Differentiate to Evaluation & Observation (the first system was built using only these classes)

Requirement to deal with Workflow - Instructions and Actions arising, recognising that Actions may occur without recorded Instructions

Differentiate Evaluation to Instruction and Action.

As people have more experience with these classes they will see how important these classes are for systems to run in a distributed environment. It would be possible to archetype each part and then specialise for the different archetypes, but very difficult to ensure that the fundamental requirements are met using models which can evolve independent of the core system.

Admin Entry is actually the Generic Entry you talk seek - this class is for administrative data as the need for protocol is not required and it does differentiate data which is of an administrative nature without using a complex ontology. This allows access for administrative purposes in a well controlled manner.

Cheers, Sam

38

Because it happens that the generic entry class (which exists in openEHR) is only useful for a) what we call Evaluations b) what we call Admininstrative Entries (AdminEntry) and c) legacy data a la 13606. It’s no use for Observations, Actions or Orders, which comprise the majority of clinical data. It’s all about data structures.

The potential to assign a wrong code always exists, everywhere, all the time. That’s just human error, and quality assurance of archetypes would try to minimise that. Just as Snomed CT’s authors try their best to minimise mistakes, nevertheless, Snomed is full of them (but they are now being reduced thankfully).

  • thomas
39

Hi Pablo,

I am just catching up with some of these discussions.

Although in theory all OBSERVATIONS must also have associated ACTIONS
to record the execution of the process, in practice this is not
necessary or the Action will refer to a group of Observations e.g. the
Action to a request to "Take Vital Signs measurements". Even if this
is recorded as part of nursing workflow, it is unlikely that each
individual Vital sign will need to have its ACTION recorded.

My priority is to ensure that the information required to support the
'real' clinical process is always available to the person reviewing
the record. So if device details are important to the clinical
interpretation of the record, we should ensure that they are part of
the OBSERVATION. The associated ACTION may be important for monitoring
care delivery but it rarely affects clinical interpretation.

The complexity of healthcare, differing use cases between unplanned
and workflowed care, primary data entry vs. messaged summaries, and
the presence or absence of a device registry, are always going to make
these decisions difficult. It is certainly possible (and cleaner) to
have references to external entities rather than them being modelled
in-line but it causes other difficulties in complicating archetype
visualisation for clinical review and of course, de-referencing for
messaging purposes.

I do agree that it would be useful if CLUSTER archetypes could be
reused between the DEMOGRAPHIC and EHR models. In fact is it quite
easy to hack the ADL to change one to another just by reaching the
EHR/DEMOGRAPHIC model name in the archetypeID but it would be better
if the tools just ignored the model part of the id.

Ian

40

Hi Pablo,

Yes, all ENTRY subtypes can include data about devices because ENTRY has a “protocol” attribute.
I believe (correct me if I’m wrong) the “protocol” attribute of an OBSERVATION can record the device and other information about the execution itself, but this should be directly related with the observed values, e.g. I don’t think I will record data about the lab device that analyzes blood samples on the blood test result. If this data is needed, maybe I record it in the ACTION that models the execution of the test, that ACTION also makes the INSTRUCTION state change to “active”.

I think I understand why an ACTION is only related to interventions, it because otherwise almost everything else would be an ACTION. If there is an INSTRUCTION to measure the Blood Pressure once a week. Then would be an ACTION to Blood Pressure too. It is important to have an ACTION archetype to interventions because it is not a normal situation, so the actor must describes what happened and record it (e.g. surgery report).

The solution to this could be to an attribute to the Archetype Model to express the criteria/rationale used to classify a concept into a certain class of the EHR Information Model, so other modellers could agree on that criteria or not and create a better classification criteria. Another idea is to created guidelines as annex to the specs to clarify gray areas with examples of modelled concepts.

Good ideas!