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

Clinical (archive)
1

I’m correcting student papers for the openEHR course in spanish.
A student has modelled oftalmologic studies for diabetic patients, with a demographic archetype of AGENT class to model all the devices used on the test.

It could be very usefull to let record the device information in the ACTION archetype to say “this is the device we use for this test”, or at the INSTRUCTION archetype to say “this is the device that should be used for the test”.

I’m sure some of you have solved this requirement, and I’ll be very thankful if you can enlight me, because I don’t see how the information model can solve this.

Thanks a lot.

2

Hi,

I’m correcting student papers for the openEHR course in spanish.
A student has modelled oftalmologic studies for diabetic patients, with a demographic archetype of AGENT class to model all the devices used on the test.

It could be very usefull to let record the device information in the ACTION archetype to say “this is the device we use for this test”, or at the INSTRUCTION archetype to say “this is the device that should be used for the test”.

I’m sure some of you have solved this requirement, and I’ll be very thankful if you can enlight me, because I don’t see how the information model can solve this.

Thanks a lot.

3

Hi Pablo,

There is a CLUSTER.device archetype - http://www.openehr.org/knowledge/OKM.html#showarchetype_1013.1.17 - plus a CLUSTER.device_details archetype - http://www.openehr.org/knowledge/OKM.html#showarchetype_1013.1.844 - that might be of interest.

These are modelled as openEHR EHR archetypes so as to be specified within the EHR itself and already used extensively within slots for many OBSERVATION archetypes eg OBS.blood_pressure. In addition, just as you are suggesting, they are intended for use within the Specific Details SLOT in the INSTRUCTION.request family of archetypes or in the Procedure Details SLOT in the ACTION.procedure archetype, as examples.

Hope this is helpful

Heather

4

Hi Pablo,
I’m an ophthalmologist and would be gladful to help.

There are some issues about the archetype class and the nature of the test. As it is a study test it must be considered the existence of an intervention. If it does not include, so the most appropriate would be to record as an OBSERVATION archetype for the test. If it includes an intervention, then the most appropriate is to record as ACTION. For both situations use the “Device” CLUSTER on the CKM to record the device, remembering this archetype is not adequate to record a substance (e.g. fluorescein).

To record the device that should be used for the test at an INSTRUCTION archetype, also consider the element “Description of Procedure” of “Procedure Request” archetype on CKM, which could be used to specify the device.

I hope it was helpful.

5

Hi Heather!

So the partern to follow is: if you have a demographic concept that should be part of the clinical record, extract the internal structure to a CLUSTER and create an slot to that. Is that the “global solution”?

BTW, there’s no device modelled as AGENT on the demographic archetypes, shouldn’t be that archetype there with an slot to the same CLUSTER?

As an example, there is openEHR-DEMOGRAPHIC-ORGANISATION.organisation.v1 and openEHR-EHR-CLUSTER.organisation.v1, so I can use the CLUSTER inside an ENTRY and inside the ORGANISATION.
The problem with those archetypes is that the ORGANIZATION doesn’t reference to the CLUSTER, and worst, they have different internal structures, Should I report this on the CKM? (maybe there are other demographic archetypes with the same problems).
In a couple of weeks I’ll have more time, if you want I can review all the problematic demographic archetypes, and propose to create CLUTERs for all the internal structures, adding a slot to that CLUSTER on those demographic archetypes. What do you think?

6

Hi Gustavo,

As Heather pointed out, the solution seems to be to reference the internal structure of a device (or any other demographic archetype) through a CLUSTER. But I think those demographic concepts should be also modelled as complete, separate demographic archetypes, referencing the same internal structure (CLUSTER). This allow us (developers) to create functionalities for searching and processing on demographic archetypes.

About the internals of a test, I think most often includes both ACTION and OBSERVATION, because an ACTION could be used when you need to record information about the execution itself (being or not a clinical intervention on the patient, e.g. the recording of the device used to make the test should be part of the ACTION not of the OBSERVATION), then the OBSERVATION(s) could hold the information about the test result or information about clinical findings during the test. Then the whole record of a test execution should be recorded into a COMPOSITION that references those ACTION(s) and OBSERVATION(s).

The INSTRUCTION of a test could reference to a device that should be used on the test, but during the test maybe another device was used, and that should be part of the ACTION that executes the INSTRUCTION.

Does this makes sense to you? Please correct me if I’m wrong.

My student detected some oftalmologic concepts that are not in the CKM, maybe I can put you both in contact to collaborate on the modelling of those concepts.

7

Hi Pablo,

it is a common mistake to tell apart ACTION and OBSERVATION. The Information Model document says:

“Observations are distinguished from Actions in that Actions are interventions whereas Observations record only information relating to the situation of the patient, not what is done to him/her.”

An OBSERVATION can record information about the execution itself, The “ECG recording” archetype, for example, includes the device. There are other OBSERVATION archetypes that include the “Device” CLUSTER (e.g. Body temperature).

Another common mistake I’ve found in CKM is to classify OBSERVATION as EVALUATION (e.g. Tobacco and Alcohol consumption). EVALUATION is an Opinion considering the Healthcare professional knowledge and OBSERVATION, not a summary of observations. But it is another topic.

I’ve also detected many ophthalmologic concepts which are not in the CKM and I have already done some of them. I’d be glad to contact your student (I was also a student of your 1st Course) so we can collaborate with each other to improve the ophthalmologic archetypes in CKM.

Best regards

8

I would say there is not a common opinion of what an evaluation is.
Some people agree with your definition, but others say that EVALUATION
is just 'the generic health care record entry with protocol'

I have seen plenty references to both and I am curious which one is
the 'correct' one.

9

Hi All

The idea of a device as an agent is interesting and at some point devices will have features of agents. The use of a re-useable cluster is clearly the solution - regardless of which part of openEHR it belongs.

The problem here is that we have demographic and EHR models - that share some classes - and an ID that requires declaration.

Generally, I think the best approach is to think if information might be in the EHR - if so, then it needs to use EHR or common classes.

Until we have a commitment to use an authorative source of IDs for archetypes regardless of where they are generated, I think we will struggle. I will say more in another post.

Cheers, Sam

10

Hi, guys
While observation is a sheer report of findings, without any judgement of value by the observator, while evaluation is the interpretation of the findings made by the interviewer, like a syndrom, a diagnosis. In psychatry is very ( or should) very easy to distinguish, mental status examination findings are observacional entries, while psychiatric case summary should be coded as evaluation ones.

11

Hi Diego

At the end of the day the EVALUATION is an information class. We have created other classes over the years to cope with information requirements that require consistent representation for computing. A lot of the information stored in this class meets the ontological scope of evaluative or summary statements - hence the name.

You feeling that it is a catch all is clearly right in the current scheme - except for administrative entries.

Cheers, Sam

12

Hello everyone,
I agree with Jussara. I think it depends on the nature of the entry.

A summary is not necessarily an opinion. If a summary is about patient’s data (e.g. physical activity summary, from NEHTA) so it should be an OBSERVATION summary. It does not include any Opinion from a healthcare professional, as it was well said by Jussara, without any judgement of value by the observer, and as defined on the Information Model document, an OBSERVATION is “any phenomenon or state of interest to do with the patient, (…) as told by the patient to the doctor, patient answers to physician questions during a physical examination, and responses to a psychological assessment questionnaire.”.

I agree that a summary can be an EVALUATION class, but only when its content is really an Opinion (based on OBSERVATIONS, published knowledge and personal knowledge). For example, I think the archetype EVALUATION.clinical_synopsis.v1 is well described according to the Information Model as a summary or overview about a patient, specifically from the perspective of a healthcare provider, and with or without associated interpretations. But on the other hand, I think the EVALUATION.substance_use_summary-alcohol.v1 is not an EVALUATION (there is no Opinion, it is all about the patient answers) and it should be incorporated within the OBSERVATION.substance_use-alcohol.v1 because it has data not included in the other alcohol archetype, e.g. Age commenced, it is also necessary to know these kind of data about alcohol use.

I’d like to know your opinion, please let me know if my understanding is wrong.

Best regards

13

Hi Pablo,
You news to be clearer about the requirement. Depending on the real requirement the student may be right.
Remember that demographic model is recording instances of parties not classes. So if the requirement is to record the specific instance of device recording attributes such serial number, last calibration date etc then he is perfectly correct to reference this instance using a participation and party ref.
However if he is just recording the type of device then you would use a protocol structure as per the blood pressure.
Including an agent object by value within an entry is not allowed and in cases where we do need to record an instance of a device by value because we don’t want the overhead of first recording the instance in a demographic repository and then referencing it then we do use the cluster approach that Heather referred to, but this is an implementation choice or even driven by the modeling process which wants to use a single model and by value associations to aid in model understanding. From experience, I don’t think it is absolutely necessary to attempt to model the party model in the cluster structure, it just makes the model hard to understand and implement.
Heath

14

Hi everyone,

The naming of the classes sometimes causes some confusion. The classic cycle diagram commonly used in training (http://www.openehr.org/wiki/download/attachments/23167000/archetype%20classes.gif), represents the classes rather simplisticly as reflecting clinical processes. And they do, to a considerable degree, but it is never quite so simple J

When deciding on an archetype class it is fundamental to decide the kind of attributes required. Usually Instruction and Action are easy to determine.

Similarly most use of OBSERVATION occurs when you want to record data that is seen, touched or measured using the same method/protocol and additionally requires any or all of: recording anytime/now, at a specific point in time or during an interval of time; mathematical/aggregate value attributes such as maximal, minimal (usually over an identified interval of time) etc; or a known state of the patient in order to interpret the data. I usually describe OBSERVATIONS as ‘the evidence’ and so some archetypes such as story don’t obviously have timing requirements (although it could potentially be useful) are modelled in this way.

And lastly, EVALUATION: quoted from http://www.openehr.org/wiki/pages/viewpage.action?pageId=786529 – “The evaluation class is the simplest of the care oriented Entry classes. It is therefore the most able to handle diverse data. The other classes are designed to meet specific requirements. The result is that the Evaluation class is best suited for information deriving from other observations where the information is of a more long-standing nature than minute to minute observations. This class also lends itself to summary or review information. Dates and times have to be explicitly represented in this class (as part of the archetype).”

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

I estimate that I have probably spent more cumulative hours trying to derive the right balance in the patterns for the alcohol & tobacco consumption archetypes than I have for any other family of models. I have tried to tease out the patterns (that are very similar), resulting in an OBSERVATION and an EVALUATION for each. I’m still not convinced it is absolutely correct yet, but while I have had a reasonable amount of pushback on the separation of models into two types, I have a very strong belief that combining them into one model will not work either – it just ain’t that simple!

– 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.

The reality is that while some of this data can be differentiated easily into one or either model, some is not so clear. For example, recording smoking status is not as simple as recording ‘currently smoking’ Yes or No in an OBSERVATION today as our clinical world, and especially the secondary reporting world, commonly uses a value set of ‘Current smoker’, ‘past or ex-smoker’ and ‘never smoked’ – with differing temporal implications. In addition, some value sets including national data dictionaries also add qualifier values such as ‘past light smoker’ and ‘past heavy smoker’, plus all the rest of examples we’ve all seen. Smoking is modelled so differently in so many places, and usually not very well – I haven’t identified a gold standard on which to base the archetypes on and would appreciate any input anyone can provide. Certainly Current smoker is implied if you enter any amount of smoking in the OBSERVATION, but while ‘never smoked’ or ‘ex-smoker’ can be recorded today, it is particularly useful to persist in records and update only if that changes.

One way to consider recording a Smoking History in an EHR might start with a persistent COMPOSITION that would be re-versioned with each smoking-related update, and comprise:

– a single EVALUATION reflecting the ‘record once only summary data’ or the ‘record in one place only’ such as cumulative consumption and which is updated as necessary, plus

– one or more instances, or links to the instances, of OBSERVATION data reflecting each ‘smoking diary’ data captured over time.

What do you think?

Cheers

Heather

15

Hi Heath,

So for demographic classes instances, the values should be linked in ENTRY.other_participations? (at the ENTRY level) or COMPOSITION.context.participations at the clinical document level? (just to be sure :slight_smile:

In the other hand, when you reference a class or an instance of that class, those structures should have something in common, since there is a semantic link between them. At the class level maybe you have the type of device, and at the instance level you should have a type too.

See the ORGANISATION example, there is a CLUSTER for organization internal structure and there is a ORGANISATION as a whole demographic archetype, and both internal structures are different. And the CLUSTER has an identifier, so could be used to reference an ORGANISATION instance. Maybe this case is just an inconsistency in the archetypes, but maybe other archetypes have the same problems.

What do you think about this rules:

  • If it’s necessary to reference an instance of a demographic class, use a DEMOGRAPHIC archetype and add the instance into the participations attribute (at the COMPOSITION or ENTRY)
  • If it’s necessary to record some attributes that can only reference a class of DEMOGRAPHIC archetypes (type of AGENT, type of PERSON, type of ORGANISATION, …), use a CLUSTER archetype to model those attributes and add the information directly into the correspondent ENTRY (using a slot to the CLUSTER in the ENTRY archetype).
  • The correspondent record of demogrpahic class attributes (type of …) and the record of instances of those classes should be consistent (class attributes should be included into instance attributes).
16

the answer is in this paper. There is a 20-page version with the detailed description of the ontology, if anyone wants it, let me know.

  • thomas
17

Hello everyone,
I agree with Jussara. I think it depends on the nature of the entry.

A summary is not necessarily an opinion. If a summary is about patient’s data (e.g. physical activity summary, from NEHTA) so it should be an OBSERVATION summary. It does not include any Opinion from a healthcare professional, as it was well said by Jussara, without any judgement of value by the observer, and as defined on the Information Model document, an OBSERVATION is “any phenomenon or state of interest to do with the patient, (…) as told by the patient to the doctor, patient answers to physician questions during a physical examination, and responses to a psychological assessment questionnaire.”.

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 agree that a summary can be an EVALUATION class, but only when its content is really an Opinion (based on OBSERVATIONS, published knowledge and personal knowledge). For example, I think the archetype EVALUATION.clinical_synopsis.v1 is well described according to the Information Model as a summary or overview about a patient, specifically from the perspective of a healthcare provider, and with or without associated interpretations. But on the other hand, I think the EVALUATION.substance_use_summary-alcohol.v1 is not an EVALUATION (there is no Opinion, it is all about the patient answers) and it should be incorporated within the OBSERVATION.substance_use-alcohol.v1 because it has data not included in the other alcohol archetype, e.g. Age commenced, it is also necessary to know these kind of data about alcohol use.

I’d like to know your opinion, please let me know if my understanding is wrong.

Questionnaires are interesting. There are two needs:

  • record the fact of the patient answering a bunch of questions at some point in time
  • use the questionnaire as an evaluation tool, rather than performing an informal assessment of the patient

If you consider Barthel, the total is out of 100 (it is supposed be thought of as a % e.g. 60% ‘independent’ etc; I think they use 20 here in the UK), but as far as I know there is no hard assessment guideline on what to do about the score value. That means the individual carer might make their own decision on what to do, based on the score. This implies that the whole Barthel questionnaire (including total) is just an ‘observation’, while an assessment based on it is an Evaluation.

Apgar is structurally the exactly the same, but there seems to be a more ‘built-in’ meaning for scores less than 7 on the second sample - can Apgar be considered something more like a ‘diagnosis’ (or at least triage) tool?

Barthel and Apgar are both designed as Observation archetypes in openEHR, as they should be in my view - because really they are tools for a guided observation process - the assessments are made by humans on the basis of the scores, not by the scores on their own.

The Alcohol use summary is an interesting example. It is currently modelled as an Evaluation. If you look at the following side-by-side comparison, there are similarities between the alcohol use summary and the Diagnosis archetype - both try to establish a temporal picture of the ‘condition’. We assume a diagnosis makes sense as an Evaluation because it is a clinical opinion - but the ‘opinion’ part is primarily in the ‘Diagnosis’ element, i..e the field where you record what the signs and symptoms equate to - diabetes or whatever - the other fields are really a choice of evidence that supports this assessment. There is no similar field in the alcohol summary archetype, which is interesting - is it really just an Observation? Food for thought.

  • thomas

18

Hi Thomas,

I am going to take Gustavo’s side on this one. I have been heavily influenced by a recent paper on JAMIA on Summarization, which makes it clear, to me at least, that some degree of summarisation takes place at every level of clinical recording,

“Summarization of clinical information: a conceptual model.” http://www.ncbi.nlm.nih.gov/pubmed/21440086

I think this is a really important paper which helps tease out some of the difficulties we have in classifying parts of the clinical recording process

Heblowitz describes the process of summarization using an AORTIS scheme.

(1) Aggregation, (2) Organization, (3) Reduction and/or Transformation, (4) Interpretation and (5) Synthesis (AORTIS).

In openEHR terms steps 1-4 would normally be OBSERVATIONS as these all apply to the evidence itself. (4) Interpretation adds some clinical interpretation but still only applies to the evidence itself e.g an ECG diagnosis of ‘atrial fibrillation’ rather than a human diagnosis (guided by the ECG result) of ‘atrial fibrillation’ .Only (5) synthesis would be an EVALUATION as it is the only step which goes beyond saying something about the evidence to saying something about the person.

A Tobacco summary is a summary of previously observed evidence, I am certainly using some clinical skill to interpret that evidence and summarise it for easier digestion, but I am not stating anything qualitatively new about the patient themselves. In AORTIS terms this is Interpretation (4)

I should add that whatever definitions and ontologies we choose they will be always be wrong!! Heather and I have had endless discussions about Tobacco archetypes and I confess to having changed my mind on several occasions. I do think, however, that we need to think very carefully about over-complicating modelling efforts, just to fit the ontology (whatever it is), particularly where these conflict with clinical recording practice That is why, I would really like to have a single Tobacco history archetype - the question of whether it is an EVALUATION or OBSERVATION is not all that important, and IMO the clear requirement to have some kind of Tobacco status record in a persistent composition should not force us to make it an EVALUATION archetype, if an OBSERVATION fits the other use cases better. We really need to make this easy for implementers - this is our prime directive, not ontology :slight_smile:

Ian

19

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.

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..

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.

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

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.

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.

Ian

20

If we take the viewpoint of this paper, we can imagine a continuum of information types more finely distinguished than the OBSERVATION / EVALUATION of today, i.e. the following:
Observation => aggregation / organisation / transformation => interpretation => Evaluation (synthesis)

Which of these is a ‘summary’ in any situation surely varies. The concrete question of interest in my view is: for a given clinical recording, what is its essential nature?

  • If it is the taking of a measurement / observation containing primary data, which must by definition occur at a certain point in time (with allowances made for time of sampling /= time of ‘observing’ sample),then it is an Observation - that’s the data structure you need to do the job of recording data in time. The Observation data structure gives you all kinds of power you don’t need unless you are actually recording observations in time.

  • If it is anything else, it is an Evaluation (i.e. excluding orders, admin data for now). That means our naming of the ‘Evaluation’ class is probably somewhat too narrow.

In concrete terms it comes down to data structures. The reason we devised the ontology for openEHR was not to impose an ontology, it was to discover what appropriate data structures were for recording real ‘data’ in time, versus recording ‘thoughts of the clinician’. Evaluation is for the latter.

  • thomas