# On-the-fly generation of an OBSERVATION Archetype based on a LOINC Panel **Category:** [Clinically Relevant RM Discussions](https://discourse.openehr.org/c/clinically-relevant-rm-discussions/129) **Created:** 2024-09-29 07:02 UTC **Views:** 88 **Replies:** 10 **URL:** https://discourse.openehr.org/t/on-the-fly-generation-of-an-observation-archetype-based-on-a-loinc-panel/5756 --- ## Post #1 by @linforest While studying the modeling patterns of the questionnaire/scale Archetypes, the following thought popped into my mind: On-the-fly generation of an OBSERVATION Archetype based on a specified LOINC Panel structure or a similiar terminologically conceptual tree... ![image|574x500](upload://qjrrCZ3NBChKTkePWwMJNNkYtkz.png) Such a kind of dynamically generated Archetypes could make the mapper's life much more easier. ``` 1..1 LOINC Panel --> Archetype root concept 0..* LOINC Term of Observation type --> ELEMENT 0..* LOINC Subpanel --> CLUSTER inside Archetype 0..* LOINC Term of Observation type --> ELEMENT 0..* LOINC Subpanel --> CLUSTER inside Archetype ... ``` Partial structure of LOINC [57022-6 CBC W Reflex Manual Differential panel - Blood](https://loinc.org/57022-6/) ![image|690x307](upload://66Pvqgiv6As0Dd1TvfkRwOQl4Sb.png) And the resulting Archetype would include term_bindings like: ``` term_bindings = < ["LOINC"] = < items = < ["at0004"] = <[LOINC::57022-6]> ["at0005"] = <[LOINC::58410-2]> ["at0006"] = <[LOINC::6690-2]> ["at0007"] = <[LOINC::789-8]> ["at0008"] = <[LOINC::718-7]> ... ["at0009"] = <[LOINC::57023-4]> ["at0010"] = <[LOINC::770-8]> ["at0011"] = <[LOINC::35332-6]> ["at0012"] = <[LOINC::19023-1]> ... ``` --- ## Post #2 by @borut.jures I work with a client which has LOINC coded all their archetypes. This allows using LOINC codes instead of AQL paths to identify the elements. An example for blood pressure (but it works the same for questionnaires) using AQL paths: ```yaml rules: archetypes: openEHR-EHR-OBSERVATION.blood_pressure.v2: name: Blood pressure uri: https://ckm.openehr.org/ckm/archetypes/1013.1.3574 formats: fhir: name: Observationbp uri: https://build.fhir.org/bp.html resource: Observation map: - path: /data[at0001|History|]/events[at0006|Any event|]/data[at0003|Data|]/items elements: systolic: diastolic: formats: fhir: - attribute: component path: code.coding.code elements: systolic: one_of: - systolic_loinc - systolic_snomed diastolic: one_of: - diastolic_loinc define: systolic: at0004|Systolic| diastolic: at0005|Diastolic| systolic_loinc: http://loinc.org/8480-6 diastolic_loinc: http://loinc.org/8462-4 systolic_snomed: http://snomed.info/id/271649006 diastolic_snomed: http://snomed.info/id/271650006 ``` This can be made generic if archetype has term bindings as you suggest: ```yaml rules: loinc: 35094-2: uri: http://loinc.org/35094-2 name: Blood pressure panel map: - attribute: data elements: systolic: diastolic: formats: fhir: - attribute: component path: code.coding.code elements: systolic: one_of: - systolic_loinc - systolic_snomed diastolic: one_of: - diastolic_loinc define: systolic: http://loinc.org/8480-6 diastolic: http://loinc.org/8462-4 systolic_loinc: http://loinc.org/8480-6 diastolic_loinc: http://loinc.org/8462-4 systolic_snomed: http://snomed.info/id/271649006 diastolic_snomed: http://snomed.info/id/271650006 ``` Notice that the last example is openEHR-neutral (I can explain in more detail how it works if there is an interest). It states a mapping from FHIR using LOINC and SNOMED CT codes alone. It could be used by any information model which has its artifacts coded. --- Mapping EHR data and interoperability is not a technical problem. Once the archetypes will be LOINC and SNOMED CT coded, the mapping will be automated. This is not a critique of the work done on existing archetypes by the clinical modelers. I'm stating my observations on a difficult future work that is still required to achieve semantic interoperability among different information models in healthcare. And this might not even be the modelers "fault" since I see that people doing the coding have titles like “Clinical Terminologist”. I guess clinical terminologists should be involved with openEHR archetype modeling too. --- I hope that one day we will be able to refer to e.g. systolic bp as http://loinc.org/8480-6 or http://snomed.info/id/271649006 instead of `/data[at0001|History|]/events[at0006|Any event|]/data[at0003|Data|]/items[at0004|Systolic|]`. There is a lot of work to be done on the LOINC and SNOMED side too. A lot of codes still need to be created. --- ## Post #3 by @linforest Such generated Archetypes would include duplicate data points in relation to those proper ones in classic Archetypes. @borut.jures May I ask a question? What mapping language are your yaml-like maps above based on? Thanks. --- ## Post #4 by @borut.jures [quote="linforest, post:3, topic:5756"] @borut.jures May I ask a question? What mapping language are your yaml-like maps above based on? Thanks. [/quote] The schema is [here](https://json.schemastore.org/mapehr.json) and a few more [examples](https://mapehr.com/docs/introduction). --- ## Post #5 by @linforest Great! It looks straightforward and human-readable. Could such a map be converted to FHIR StructureMap? --- ## Post #6 by @siljelb I have some thoughts about this. There may of course be other examples where this is more useful, but for things like (clinical biochem) lab analytes or panels, I wouldn't want specific archetypes (generated or not) for each of them. Why? Because there are thousands of them, and they will need to be governed. Additionally, a lab result OBSERVATION will need to contain a lot of additional elements not part of the LOINC panels. This is an area where information models and terminology work really well together, by using the analyte terms from LOINC, NPU or whatever within more generic information models like [Laboratory test result](https://ckm.openehr.org/ckm/archetypes/1013.1.2191) and [Laboratory analyte result](https://ckm.openehr.org/ckm/archetypes/1013.1.2881). Could maybe generating templates or maybe even just terminology bindings, create similar kinds of effects without the drawbacks of generating archetypes? --- ## Post #7 by @borut.jures [quote="siljelb, post:6, topic:5756"] Could maybe generating templates or maybe even just terminology bindings, create similar kinds of effects without the drawbacks of generating archetypes? [/quote] The client I mentioned has solved this for 3000+ lab archetypes. As far as I can tell they used a combination of generated archetypes and templates with LOINC coding (so everything you mentioned :sweat_smile:). I cannot speak about their work (my part is only generating demo instances for these lab OPTs), but maybe they will decide to comment here. I can share an example formula that clinicians write for setting random values and then use it for the interpretation (notice the use of only a LOINC code so the formula can be used by different information models): ``` # The normal range is 3.4 to 5.4 g/dL (34 to 54 g/L). # Source: https://www.ucsfhealth.org/medical-tests/albumin-blood-(serum)-test 1751-7: uri: http://loinc.org/1751-7 name: Albumin [Mass/volume] in Serum or Plasma set: - attribute: value element: value_intervals: g_dL_snomed: 2.5..6.5 g_L_snomed: 25..65 interpretation_intervals: g_dL_snomed: low: 3.4 high: 5.4 g_L_snomed: low: 34 high: 54 ``` --- ## Post #8 by @borut.jures [quote="linforest, post:5, topic:5756"] Could such a map be converted to FHIR StructureMap? [/quote] FHIR StructureMap and the FHIR Mapping Language are possible representations of EHR data mapping however in my experience they come short when complex conditions are required. This is why I decided to support the use of a full programming language (see at the end of this [example](https://mapehr.com/docs/introduction#use-other-elements-to-calculate-a-value)). YAML is great but healthcare data is too complex for YAML. It is good to be able to use code when needed. Another difference to StructureMap is integrated post-processing of the mapped data. Calculating Body Mass Index (BMI) is such an example. For this calculation we use mapped elements to calculate a value of another element. I wanted to support such use cases in the same YAML and avoid using another tool for the post-processing. Person with clinical knowledge who will write the mapping rules also has the knowledge how other data needs to be calculated. They can use the same YAML to specify additional [post-processing rules](https://mapehr.com/docs/introduction#use-other-elements-to-calculate-a-value) so that they don’t have to rely on others (e.g. programmers) to do it for them. --- ## Post #9 by @linforest @siljelb You know, there are so many lab tests and panels **AND their countless combinations** that mappers would face significant manual workloads even with models like [Laboratory test result](https://ckm.openehr.org/ckm/archetypes/1013.1.2191) and [Laboratory analyte result](https://ckm.openehr.org/ckm/archetypes/1013.1.2881) available. @borut.jures Thanks a lot for your valuable sharing! --- ## Post #10 by @ian.mcnicoll [quote="borut.jures, post:7, topic:5756"] The client I mentioned has solved this for 3000+ lab archetypes. [/quote] That is the problem Lab panels vary enormously even within single countries. At least for lab, we specifically designed the archetypes to be integration driven and not to have specific lab analyte/panel targets. >Could maybe generating templates or maybe even just terminology bindings, create similar kinds of effects without the drawbacks of generating archetypes? One option worth exploring, I think is the FHIR ObservationDefinition - more of a lightweight set of reference metadata than full models. --- ## Post #11 by @linforest A related reference: An OpenEHR Template with the Integrated German LOINC Terms Abdul-Mateen Rajput et al. Stud Health Technol Inform. 2021. https://pubmed.ncbi.nlm.nih.gov/34042864 --- **Canonical:** https://discourse.openehr.org/t/on-the-fly-generation-of-an-observation-archetype-based-on-a-loinc-panel/5756 **Original content:** https://discourse.openehr.org/t/on-the-fly-generation-of-an-observation-archetype-based-on-a-loinc-panel/5756