Speaking in RIM grammar

Sep 24, 2011

On Thursday and Friday this week, I held a a two day course teaching how to map from Australian v2 messages to Australian CDA documents. My course went a lot further than Keith’s excellent chapter in his CDA book on the subject, because the mappings were made in the presence of both v2 and CDA implementation guides (Australian Standards and NEHTA specifications). As part of the course, I tried to teach the attendees how to speak in RIM grammar - you need to, in order to map miscellaneous v2 concepts- there’s a lot of them - into the clinical statement pattern. Obviously there’s a lot of prior art about -the NEHTA specifications and more widely, the combined IHE/HL7 implementation guides and most of all the consolidated health story Implementation Guide - but it’s common to encounter data concepts that simply haven’t been mapped to any clinical statement pattern, let alone the simple one in CDA. So here’s a quick and simple way to learn to speak things in the RIM grammar.

Step #1: Basic Grammar

The basic grammar of the RIM is Act-Participation-Role-Entity. Learning how to speak this language is as easy is filling in the following sentences:

  • Act: “[W] is something that happens or could happen”
  • Participation: “[Y] is the [X] in [W]”
  • Role: “[Z] is capable of being a [Y]”
  • Entity: “[Z] is something that actually exists at least for a while” (i.e. doesn’t exist as a record)

where:

  • W is a display name from the ActClass heirarchy
  • X is a display name from the ParticipationType heirarchy
  • Y is a display name from the RoleClass heirarchy
  • Z is a display name from the EntityClass heirachy

It’s simply a case of looking through those code systems and picking a code. Here’s an example:

  • E: “[person] is something that exists at least for a while”
  • R: “[person] is capable of being a [patient]”
  • A: “[encounter] is something that happens or could happen”
  • P: “[patient] is the [subject] in [encounter]”

Except that this isn’t simple. There’s a few complicating factors

  • put like this, it’s not clear how the act code, role code, and entity code interact with the class codes - this makes it hard to know quite what kind of term of you’re looking for in the act heirarchy particularly
  • Also, verbs and nouns have nothing to do with acts or not, and somethings that look like entities (Documents, Accounts) are actually acts
  • it’s hard to pick the right role code - the role code hierarchy is a mess
  • RIM classCodes and RIM classes are interlaced (the actual RIM class hierarchy doesn’t match the actual RIM class hierarchy)

The only way to work your way through these is practice, with a v3 specialist to help.

Step #2: Mood Codes

The second step is to pick the right mood code. This is easy:

  • Intent: “[W] is something that we intend to make happen”
  • Appointment: “[W] is something that is expected to happen at a set time”
  • Appointment Request: “Please give us a time for [W] to happen”
  • Promise: “[W] is promised to happen” (or I promise to do [W])
  • Proposal: “It would be good if [W] happens”
  • Request: “I would like it if [W] happens” (or “Please do [W]”)
  • Definition:    “This is what [W] looks like if/when it happens”
  • Event:“[W] is something that happened”
  • Criterion: “If [W] happens”
  • Goal: “Getting [W] to happen is our goal”

Step #3: Act Relationships

This sentence is easy:

  • “[source act sentence ]” [V] “[target act sentence]”

where V is a displayName taken from ActRelationship type. That’s enough - you could go on and define RoleLink, and playing and scoping entity, but by the time people have mastered these, they’ve got the principles. It’s useful to understand the methodology, but you always have to consult prior art:

  • Domain Models
  • CDA Implementation Guides
  • National Program specifications (if you can get them)

It also helps to have a v3/RIM specialist on hand. Even then, you can still get confusion and contention about the “right way” to represent a notion using RIM grammar - because like all good grammars, it’s ambiguous. There’s a confusion here -the idea of the RIM isn’t to create a meaningful ontology that you can reason with, nor to offer useful leveragable logical grammar for implementors - it’s a tool to ensure consistent model definitions (and it addresses only some of those issues). That’s why, in RFH, we’re keeping the this whole RIM grammar away from the resource models, in the background where it’s exercised by RIM specialists to ensure the models are robust.