Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Setting the Scene

These pages deal with the key challenge of designing information model ('IM') structures - mostly represented in openEHR as archetypes - and terminology to be semantically equivalent. Why are they not just the same? For many reasons: archetypes are about what information is useful to gather; terminologies (of the ontological kind, like SNOMED CT, and weakly, ICDx, ICPCx) are about what facts are true of certain categories of phenomena of interest in the domain. Thus, an archetype can be designed to represent the common post-partum Apgar data and scores at 1 minute and 5 minutes, whereas an ontology would not necessarily choose either the same data points or time points - neverthless the data points in the archetype should relate to (some) concepts (somewhere) in the terminology, and more importantly, should not violate any underlying ontological rules

...

The structural way

The terminology way

parent node

  • site = !hand!
  • laterality = !left!

parent node

  • site = !left hand!

It is probably obvious to most people why the left side is naive. The problem here is one of ensuring semantic correctness. There will be no problem if only 'left hand' and 'right hand' are used. But what about site = left hand, laterality = right? Or perhaps someone might decide that 'inside' and 'outside' were reasonable as lateralities. Further, not all sites have laterality. And 'left kidney' means a separate organ, whereas 'left lobe of liver' does not. The naive approach leaves it to the information modeller and system to get this right, but in fact the only sure way to do so is with an ontological model of anatomical parts and relationships, which is precisely what a good terminology should be based on. We can also see that the laterality field is unlikely to have any functional use on its own, e.g. as a target of querying (one would never query for all 'left' body sites in an EHR). So it seems pretty clear that the ontological modelling approach is better: it trusts the terminology to know what things have lateralities, and what the possibilities might be, e.g. not only left, right, but upper, lower, superior etc, and also distinguishes properly between the left side of the left eye, and the left side of the right eye, and so on.

...

Purely structural way

Hybrid way

Pure terminological way

parent node

  • problem = !lobar pneumonia!
  • date_clinically_recognised = 2008-07-22
  • body_site = !lung, upper lobe!
  • laterality = !left!
  • severity = !severe!
  • causitive_agent = !Streptococcus pneumoniae!
  • date_of_onset = 2008-07-15

parent node

  • problem = !lobar pneumonia!,!severity! = !severe!
  • date_clinically_recognised = 2008-07-22
  • body_site = !finding_site!= !Structure of upper lobe of lung!,!laterality! = !left!
  • causitive_agent = !Streptococcus pneumoniae!
  • date_of_onset = 2008-07-15

parent node

  • finding = !lobar pneumonia!:
    !finding_site! = !structure of upper lobe of lung!,
    !laterality! = !left!,
    !causative_agent! = !Streptococcus pneumoniae!,
    !severity! = !severe!
  • non-codable attributes?

...

Here is an example from the slides (slide 59) of the clinical statement 'knee jerk reflex reaction = ++', drawn out as a tree, with relationship terms in blue:

SNOMED expression

openEHR expression

Situation
Group

  • associated_finding = !clinical_finding!
    • Group
      • has_interpretation = !++!
      • interprets = !knee jerk reflex!
  • finding_context = !known present!
  • temporal_context = !current or specified time!
  • subject_relationship_context = !subject of record!

OBSERVATION

  • subject = PARTY_SELF (i.e. subject of record)* provider = PARTY_IDENTIFIED [id info of physician]
  • data = HISTORY
    • origin = 2009-03-04T13:20:00
    • events = EVENT
      • offset = P0s
      • data = ITEM_LIST
        • items =
          • [1] =ELEMENT
            • name = !knee jerk reflex, lateriality = left!
            • value = DV_ORDINAL ++
          • [2] =ELEMENT
            • name = !knee jerk reflex, lateriality = right!
            • value = DV_ORDINAL +++
          • [3] =etc
      • protocol = ITEM_TREE
        • items = ....

...