Seeking clarification regarding Assumed value

Clinical (archive)
1

Hi everyone,

Assumed value - https://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_assumed_value

I’ve spoken to Sam Heard on many occasions and I have understood him to say that the intent for an assumed value to only be relevant for ‘State’ in an OBSERVATION. But never in ‘Data’. This is what I’ve always taught modellers.

The original Ocean Archetype Editor, had this implemented. In more recent years ‘assumed value’ was implemented across all of the parts of the OBSERVATION. Incorrectly, as I understand it, but the code was never reviewed nor updated.

We are now debating how this should be implemented in the new ADL Designer, and I’m seeking clarification.

It makes sense to be able to potentially have an assumed value for ‘State’ – for example the position of the patient if it is always the same in 99% of use cases. The theory, as I understand it, is that in this situation the position will only be recorded if the assumed value is modified from the assumed value. (Mind you, if the assumed value is excluded/zero occurrence in an implemented template, it will not necessarily be a valid assumption, but let’s keep that argument about whether assumed values are reasonable at all for later).

The discussion is often further compounded by confusion about default vs assumed values.

I don’t think that it makes any sense to allow an ‘assumed value’ for actual data values eg a Systolic Blood Pressure measurement – especially if, as per the specs link (above), “The notion of assumed values is distinct from that of ‘default values’. The latter is a local requirement, and as such is stated in templates; default values do appear in data, while assumed values don’t.”

My question to the list: Data values need to be recorded explicitly and should never be assumed – True or False?

Thanks

Heather

Dr Heather Leslie

MB BS, FRACGP, FACHI, GAICD

M +61 418 966 670

Skype: heatherleslie

Twitter: @atomicainfo, @clinicalmodels & @omowizard

www.atomicainformatics.com

2

Hi Heather,

Purely technically, I think the answer is “false” - since assumed values are an available independent of their context (e.g. data or state).

But for all practical modelling I think the answer is “true” – assumed_value should really be used for protocol/state, but not data.

As for the tooling, there’s always a bit of tension between these two, i.e. how generic such tools can and should be, what should be exposed to the UI and what maybe not.

Sebastian

(attachments)

image001.jpg

3

I totally agree with Sebastian, that’s a fight we have had for years while implementing LinkEHR.
You can of course create an ad hoc tool for openEHR, including all the usability and additional rules you want. But if your tool is really generic (i.e. based in a BMM definition of the reference model), it will be difficult to implement those rules.

(attachments)

image001.jpg
image001.jpg

4

Hi Heather,

I think I’ve tracked down why this was changed in the Ocean Archetype Editor. It seems to be this change on 6th May 2012:

https://github.com/openEHR/arch_ed-dotnet/commit/bb50d16ad44e910d717c9e75e967fe1b1af36c46

EDT-567: Allow assumed value to be set on any data, not just on patient state, for DV_TEXT and DV_BOOLEAN.

It was our good friend Ian McNicoll who raised this change request … on 30th Jul 2009. (My, how the years do pass!) Ian marked the priority as major (though it took me a few years to get around to “fixing” it). Here’s what Ian wrote in Jira:

‘Assumed value’ can only be entered via Patient State - needs to be available throughout

Description

The option to enter an assumed value only appears when a data element is being added within patient state. As far as I can tell this is a local implementation issue and not a requirement of the AOM.

We are increasingly making use of CLUSTER archetypes such as Ambient_oxygen.v1 which, of course, have no state attribute, but which depend on having assumed values for some elements, in this case the flow rates and oxygen proportions.

I have logged this as major since Ambient_oxygen is an openEHR CKM archetype on which a number of other soon to be published OBSERVATIONS will depend.

Attached to this email is the CLUSTER that Ian attached to the Jira issue.

(attachments)

openEHR-EHR-CLUSTER.ambient_oxygen.v1.adl (3.9 KB)

5

...Attached to this email is the CLUSTER that Ian attached to the Jira issue.

Hmmm, I don’t think this mailing list accepts attachments. Here is the CLUSTER as ADL.

Peter

archetype (adl_version=1.4)
  openEHR-EHR-CLUSTER.ambient_oxygen.v1

concept
  [at0000] -- Ambient oxygen
language
  original_language = <[ISO_639-1::en]>
  translations = <
    ["de"] = <
      language = <[ISO_639-1::de]>
      author = <
        ["organisation"] = <"University of Heidelberg, Central Queensland University">
        ["name"] = <"Jasmin Buck, Sebastian Garde">
      >
    >
  >
description
  original_author = <
    ["name"] = <"Ian McNicoll">
    ["organisation"] = <"Ocean Informatics">
    ["email"] = <"ian.mcnicoll@oceaninformatics.com">
    ["date"] = <"08/06/2009">
  >
  details = <
    ["en"] = <
      language = <[ISO_639-1::en]>
      purpose = <"To record the amount of oxygen being delivered to the subject at the time of observation. Assumed values of 21% O2, Fi02 of 0.21 and Oxygen flow rate of zero.">
      use = <"May be used within an ACTION archetype to specificy oxygen therapy , or within OBSERVATION archetypes such as Blood gases or Respirations, as part of patient state, where knowledge of ambient oxygen status is critical to interpretation of the observation.

">
      keywords = <"breathing", "oxygen">
      misuse = <"">
      copyright = <"copyright (c) 2009 openEHR Foundation">
    >
  >
  lifecycle_state = <"AuthorDraft">
  other_contributors = <"Heather Leslie Ocean Informatics", "Sebastian Garde Ocean Informatics", "Andrew James University of Toronto", "Sundarasan Jaganathan NHS Scotland", "Omer Hotomargolu Turkey", "Marja Buur Medisch Centrum Alkmaar Netherlands", "Gregory Caulton PatientOS Inc.", "Anne Harbison CPCER", "Sam Heard Ocean Informatics">
  other_details = <
    ["references"] = <"">
    ["MD5-CAM-1.0.1"] = <"1FCF286B5D47164C5D89907DF332BC65">
  >

definition
  CLUSTER[at0000] matches { -- Ambient oxygen
    items cardinality matches {0..*; unordered} matches {
      ELEMENT[at0051] occurrences matches {0..1} matches { -- Oxygen flow rate
        value matches {
          C_DV_QUANTITY <
            property = <[openehr::126]>
            list = <
              ["1"] = <
                units = <"l/m">
                magnitude = <|0.0..50.0|>
                precision = <|1|>
              >
              ["2"] = <
                units = <"ml/min">
                magnitude = <|0.0..50000.0|>
                precision = <|1|>
              >
            >
            assumed_value = <
              magnitude = <0.0>
              units = <"l/m">
              precision = <1>
            >
          >
        }
      }
      ELEMENT[at0052] occurrences matches {0..1} matches { -- FiO2
        value matches {
          DV_PROPORTION matches {
            numerator matches {|0.0..1.0|}
            is_integral matches {False}
            type matches {1}
          }
        }
      }
      ELEMENT[at0053] occurrences matches {0..1} matches { -- Percent O2
        value matches {
          DV_PROPORTION matches {
            numerator matches {|0.0..100.0|}
            is_integral matches {False}
            type matches {2}
          }
        }
      }
    }
  }

ontology
  term_definitions = <
    ["de"] = <
      items = <
        ["at0000"] = <
          text = <"*Ambient oxygen(en)">
          description = <"*The amount of oxygen being delivered to the subject at the time of observation. Assumed values of 21% O2, Fi02 of 0.21 and Oxygen flow rate of zero.(en)">
        >
        ["at0051"] = <
          text = <"*Oxygen flow rate(en)">
          description = <"*Flow rate of inspired oxygen.(en)">
        >
        ["at0052"] = <
          text = <"*FiO2(en)">
          description = <"*Fraction of inspired oxygen.(en)">
        >
        ["at0053"] = <
          text = <"*Percent O2(en)">
          description = <"*Percentage of inspired oxygen.(en)">
        >
      >
    >
    ["en"] = <
      items = <
        ["at0000"] = <
          text = <"Ambient oxygen">
          description = <"The amount of oxygen being delivered to the subject at the time of observation. Assumed values of 21% O2, Fi02 of 0.21 and Oxygen flow rate of zero.">
        >
        ["at0051"] = <
          text = <"Oxygen flow rate">
          description = <"Flow rate of inspired oxygen.">
        >
        ["at0052"] = <
          text = <"FiO2">
          description = <"Fraction of inspired oxygen.">
        >
        ["at0053"] = <
          text = <"Percent O2">
          description = <"Percentage of inspired oxygen.">

6

I asked for this to be changed as we had dropped inspired oxygen into a cluster archetype (intended to sit in state and wanted to be able to state the assumed value of 23% (or whatever).

I have come round to thinking that Assumed value is actually unhelpful. It is only a statement on the archetype and never ends up in the data, and completely non-processable. I think it can be easily misunderstood and is often very difficult to assert reliably. I would not be unhappy it see it dropped.

We will however definitely need default values in specialisations e.g the lab series.

Ian

Ian

7

Assumed value was a slick idea at the time, but I do agree with your sentiments now:

  • it is hardly or not at all processable,
  • where there is widespread consensus on something it may well be assumed automatically by clinicians – but this is not because someone put the assumed value in the archetype or not.
  • Elements where such consensus exists across professions/sectors are probably rare anyway and universal consensus on an assumption is hard to ascertain
  • challenges for UI
  • challenges for querying (assuming you even dare)
  • challenges for anybody to understand it, including the difference to a default value (and what happens if there is both).

Not sure about the implications for dropping/deprecating this at this stage

Sebastian

8

Thanks Sebastian,

You summarised my views much better than me.

As policy, I think we should stop using it for future archetypes, and simply use the metadata to declare ‘assumptions’ where they make sense, although I agree it is very risky to assert ‘x’ where data is simply missing.

Ian

9

It is still in ADL2, but harmless, so I would leave it in the specs and advise tool developers to ignore it, if that is the consensus.

  • t
10

“It is still in ADL2, but harmless, so I would leave it in the specs and advise tool developers to ignore it, if that is the consensus.”

That would be my preference. Perhaps add a note to the specs explaining why it is being deprecated (if others agree).

11

Good conclusion from my point of view.

Thanks everyone!

Cheers

Heather