Coding element and event names

Specifications
41

Yes sure - that is valid ADL1.4 but that’s overriding the .name attribute by sub-classing it to a DV_CODED_TEXT, rather than specialising the archetypeId itself , which is what will happens in ADL2

So conceptually more like

EVENT[at0002.1] occurrences matches {0..*} matches {    -- Any event
		name matches {
			DV_CODED_TEXT matches {
				defining_code matches {
					[SNOMED-CT::10987654321]
				}
			}
		}

The approach you are suggesting, I did try in the past as a way of ‘labelling’ lab tests with LOINC or other external terms. I took this it @borut.fabjan and he was not keen on the idea, though accepted it is technically acceptable from an RM Pov.

His argument (I think) was that esp with AD2, things start to get messy , especially if we are using run-time name constraints, and then perhaps having to add external codings.

He did persuade me that it may be cleaner to use term_mappings , and leave the original defining_code as whatever was defined in the archetype.

That has its own issues of course in terms of tooling support.

1 Like
42

If I understand correctly, your example is conceptually different from what I’ve hacked together? If so, in what way is it different? :smile:

43

@yampeku -could you send me through the ADL that sits behind your Linkehr archetype snippet - basically we need the same structure but associated with LOCATABLE.name .

I am tryintg to edit manually and getting confused, especially handling multiple mapping constraintse.g a LOINC mapping and a SNOMED mapping.

EVENT[at0006] occurrences matches {0..*} matches {    -- Any event
						data matches {
							ITEM_TREE[at0003] matches {    -- blood pressure
								items cardinality matches {0..*; unordered} matches {
									ELEMENT[at0004] occurrences matches {0..1} matches {    -- Systolic
										name matches {
                                       		DV_TEXT  matches {
                                                  mappings = matches
                                                   matches TERM_MAPPING
....
                                                  >
                                               >
                                            }
44

Something like this?

     ELEMENT[at0005] occurrences matches {0..1} matches {  -- Código SPREC
          value existence matches {0..1} matches {
              DV_TEXT[at0006] occurrences matches {0..1} matches {  -- DV_TEXT
                  value existence matches {1..1} matches {/.*/}
              }
          }
          name existence matches {1..1} matches {
              DV_TEXT[at0002] occurrences matches {0..1} matches {  -- DV_TEXT
                  mappings existence matches {0..1} cardinality matches {0..*; unordered; unique} matches {
                      TERM_MAPPING[at0025] occurrences matches {0..*} matches {  -- TERM_MAPPING
                          target existence matches {1..1} matches {
                              [ac0001]
                          }
                      }
                  }
              }
          }
      }

Probably remove the at code in TERM_MAPPING as that will make it to not parse on AD

1 Like
45

Can you take it down a level under target existence matches {1..1} matches { [ac0001]

to use something like

target existence matches {1…1} matches {
CODE_PHRASE occurrences matches {1…1} matches {
code_string existence matches {1…1} matches {“123445678”}
}

However, I can see that this is setting a constraint, when what we really want is to set a default value??

Help!!

46

So if I understand this correctly, since this is a /name/mappings/target/code_string instead of name/defining_code/code_string, it’s easier to handle technically?

And an AQL path for this would be something like
[openEHR-EHR-OBSERVATION.problem_screening.v1]/data[at0001]/events[at0002]/data[at0003]/items[at0022, and name/mappings/target/code_string='5' and name/mappings/target/terminology_id/value='my_local_terminology']/items[at0005]?

47

[openEHR-EHR-OBSERVATION.problem_screening.v1]/data[at0001]/events[at0002]/data[at0003]/items[at0022, and name/mappings/target/code_string='5' and name/mappings/target/terminology_id/value='my_local_terminology']/items[at0005] MY Terminology`

Yes. There are some discussion about making this a bit easier with something like

OBSERVATION.problem_screening.v1]/data[at0001]/events[at0002]/data[at0003]/items[at0022].CODE_PHRASE_MATCHES(“5:MY Terminology)”

which would also check in both the name.defining_code and mappings.target for a matching CODE_PHRASE, though this is more helpful when check for matches on the value side

I’ve been trying to explain to myself the challenge with the name-> DV_CODED_TEXT approach, and it mainly comes down to the fact that in ADL2, name becomes associated with the atCode introduced by the template.

Then if you (legally) sub-class /name/value to a DV_CODED_TEXT the name/value becomes associated with the defining_code in name.

Archetype - level

  .archetype_node_id = 'at0002'
  .name <DV_TEXT>
      .value = 'Any Event'

ADL2 Template - level

  .archetype_node_id = 'at0002.1'
  .name <DV_TEXT>
      .value = 'My Template atCode term'

ADL2 Template - level with name → DV_CODED_TEXT

 .archetype_node_id = 'at0002.1'
  .name <DV_CODED_TEXT>
      .value = 'SNOMED CT term'
     -defining_code
        .code_string = '1234567'
        .terminology_id 'SNOMED-CT'

It is all legal but it is starting to get pretty convoluted to explain and implement in comparison with using term mappings.

  .archetype_node_id = 'at0002.1'
  .name <DV_TEXT>
      .value = 'My template atCode term'
      .mapping
        . target
           .code_string = '1234567'
           .terminology_id = 'SNOMED-CT'
           .preferred_term'' = 'SNOMED Term'

which more nicely maps into FHIR CodableConcept and avoids sub-classing which is elegant in modelling terms but a pain technically.

.value = 'My Template atCode term'
.coding[0]
      code = 'at0002.1'
      system = 'local'
      display  ='My Template atCode term'
.coding[0]
      code = '123456'
      system = 'SNOMED-CT'
      display  ='SNOMED term'

The downside of mappings is that they are not supported in tooling well but we really need to solve that problem in any case, for all sorts of other reasons.

48

Wouldn’t that be the assumed value of the string? This is supported in strings

   name existence matches {1..1} matches {
       DV_TEXT[at0002] occurrences matches {0..1} matches {  -- DV_TEXT
           mappings existence matches {0..1} cardinality matches {0..*; unordered; unique} matches {
               TERM_MAPPING[at0025] occurrences matches {0..*} matches {  -- TERM_MAPPING
                   target existence matches {1..1} matches {
                       CODE_PHRASE[at0026] occurrences matches {1..1} matches {  -- CODE_PHRASE
                           code_string existence matches {1..1} matches {/.*/; "123445678"}
                       }
                   }
               }
           }
       }
   }
49

I don’t think ‘assumed_value’ is correct - that is not intended to be a ‘default’ it is a design_time suggestion that if e.g ‘Position’ is missing then you might possibly assume that the patient is ‘lying down’.

However, thanks, this has clarified for me that containing mappings is not the way to go in terms of ‘asserting’ bindings to be carried into the record (however we do it).

1 Like
50

Could it mean “if no code is present then we can assume this one”? As we want recommendations probably is the closest we can get without introducing a constraint without the ability of putting the new keywords

51

For me that is a ‘default value’ i.e it is safe to populate the record with this value, if now is given.

‘Assumed’ is much softer - it just means at a human level you might be safe to assume that the ‘patient was lying down’ but TBH, I don’t think we use that now at all, as IMO it is unhelpfully confused with ‘default’ and would be better just expressed in description or comment as narrative.

2 Likes
52

We should probably deprecate this assumed value…You have given the main, maybe even the only example for it that I have ever heard, and even there it seems of dubious value to me.

3 Likes
53

It was an idea of Sam’s (and maybe Dipak), from close to 20y ago. It was something I think they thought would generalise across medicine, but over time the only examples that have ever emerged always seem to have been patient position during BP measurement and exertion during heart rate measurement.

For good or bad, we have engineered the capability to have ‘assumed values’ in any primitive data type. This could potentially be used as is to implement some sort of default values, but since default values need to be definable for larger granularity objects (potentially even up to whole Observations) it might be better to deprecate it.

3 Likes
54

I think nowadays we use annotations for this extra info

By the way, if I remember correctly there are archeytpes in CKM with assumed values

55

Definitely the v1’s of Blood pressure and Pulse/Heart beat, but both have been superseeded by v2 without any assumed_values.

There are few others in drafts, e.g. Swallowing in

ELEMENT[at0011] occurrences matches {0..1} matches {	-- Swallowing
	value matches {
		0|[local::at0012], 	-- Unable to swallow
		1|[local::at0013], 	-- Some ability to swallow
		2|[local::at0014], 	-- Reduced swallow
		3|[local::at0015]; 	-- Normal
		0  	-- assumed value
	}
}

where the assumed_value is “Unable to Swallow”.

1 Like
56

That OBS.infant_feeding archetype is really old, in draft and also a mix of volume and the infants “feeding function”, and the archetype should most likely be deprecated or moved to the “Archetype graveyard” incubator.

It would be interesting to know if there are any assumed value in published archetypes.

1 Like
57

Yes - assumed values are quite hard to search for (due to the common syntax where the assumed value is just separated with a "; ").
I have found 13 active archetypes where the current revision has at least one assumed value. All of them have a DRAFT or INITIAL status:

[
  {
    "cid": "1013.1.250",
    "resourceMainDisplayName": "Feeding",
    "resourceMainId": "openEHR-EHR-OBSERVATION.infant_feeding.v0",
    "status": "DRAFT",
    "projectName": "Common resources"
  },
  {
    "cid": "1013.1.1370",
    "resourceMainDisplayName": "Visual field measurement",
    "resourceMainId": "openEHR-EHR-OBSERVATION.visual_field_measurement.v0",
    "status": "DRAFT",
    "projectName": "Ophthalmology domain"
  },
  {
    "cid": "1013.1.1677",
    "resourceMainDisplayName": "Audiogram test result",
    "resourceMainId": "openEHR-EHR-OBSERVATION.audiogram_result.v0",
    "status": "DRAFT",
    "projectName": "Hearing"
  },
  {
    "cid": "1013.1.1689",
    "resourceMainDisplayName": "Acquisition details on eye fundus images",
    "resourceMainId": "openEHR-EHR-CLUSTER.acquisition_details_on_eye_fundus_images.v0",
    "status": "INITIAL",
    "projectName": "AMD, Diabetic Retinopathy & Glaucoma"
  },
  {
    "cid": "1013.1.1823",
    "resourceMainDisplayName": "Recommendation on the treatment of AMD",
    "resourceMainId": "openEHR-EHR-EVALUATION.recommendation-amd_treatment.v0",
    "status": "INITIAL",
    "projectName": "AMD, Diabetic Retinopathy & Glaucoma"
  },
  {
    "cid": "1013.1.1845",
    "resourceMainDisplayName": "Tympanogram test result - 226Hz",
    "resourceMainId": "openEHR-EHR-OBSERVATION.tympanogram_226hz.v0",
    "status": "DRAFT",
    "projectName": "Hearing"
  },
  {
    "cid": "1013.1.2015",
    "resourceMainDisplayName": "Central corneal thickness details",
    "resourceMainId": "openEHR-EHR-CLUSTER.corneal_thickness_details.v0",
    "status": "INITIAL",
    "projectName": "AMD, Diabetic Retinopathy & Glaucoma"
  },
  {
    "cid": "1013.1.2159",
    "resourceMainDisplayName": "Recommended treatment for glaucoma",
    "resourceMainId": "openEHR-EHR-EVALUATION.recommendation-glaucoma_treatment.v0",
    "status": "INITIAL",
    "projectName": "AMD, Diabetic Retinopathy & Glaucoma"
  },
  {
    "cid": "1013.1.2350",
    "resourceMainDisplayName": "Hearing screening test result",
    "resourceMainId": "openEHR-EHR-OBSERVATION.hearing_screening_result.v0",
    "status": "DRAFT",
    "projectName": "Hearing"
  },
  {
    "cid": "1013.1.2512",
    "resourceMainDisplayName": "Mydriasis application",
    "resourceMainId": "openEHR-EHR-CLUSTER.mydriasis_application.v0",
    "status": "INITIAL",
    "projectName": "AMD, Diabetic Retinopathy & Glaucoma"
  },
  {
    "cid": "1013.1.2859",
    "resourceMainDisplayName": "Microscopy renal biopsy non neoplastic",
    "resourceMainId": "openEHR-EHR-CLUSTER.microscopy_renal_biopsy_non_neoplastic.v0",
    "status": "DRAFT",
    "projectName": "Norwegian referenced archetypes"
  },
  {
    "cid": "1013.1.3556",
    "resourceMainDisplayName": "Jugular venous pressure",
    "resourceMainId": "openEHR-EHR-OBSERVATION.jugular_venous_pressure.v0",
    "status": "DRAFT",
    "projectName": "Common resources"
  },
  {
  <!-- This one sits in a private incubator. -->
    "cid": "1013.1.3358",
    "resourceMainDisplayName": "Histoimmunogenetic typing",
    "resourceMainId": "openEHR-EHR-CLUSTER.histoimmunogenetic_typing.v0",
    "status": "INITIAL",
    "versionAsset": 1,
    "versionAssetLatest": 1,
  }
]
2 Likes