Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Two more examples. Representing the information 'procedure site' in the information model... two choices:

[NOTE: FOR THE MOMENT, THE USUAL '|' character has been changed to '!' because '|' cannot be used in tables, even when quoted in Confluence wiki markup. We hope this is temporary]

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?

In the pure structural approach, we see the same problem as in the earlier example: laterality is on its own. Similarly, 'severity' is also on its own, when in all likelihood it should be associated with the symptom, since by the same argment as above, only a proper ontology is going to know that 'mild rash' is sensible, but 'mild pregnancy' is not (or even 'mild cardiac arrest', if we want to stick to possible substance reactions).

...

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

...