SMIRF

Note: discussion of the SMIRF concept has largely moved to a discussion around the persistence of FHIR Resources. The Resource concept is akin to the SMIRF concept.

Rationale

The concept documented on this page was created based on current experiences with OLAP style databases (where versioning is based on individual objects, and where conceptually the persistence layer is an object graph). This turns out to have various disadvantages: it is too fine grained to be useful as a unit for processing and versioning. The well known alternative (OLTP, persisting a stack of messages) has drawbacks as well: message is too coarse in terms of granularity.

Ewout: The whole idea behind these SMIRFS was that when you read the implementation guide for a certain HL7v3 message exchange, you have an exact idea of what the message is trying to convey, so by reading the guide you get an idea of the semantics of the message, and the way that they are modeled in these interactions. You can then map them safely to your SMIRFS, your fixed model, which has agreed semantics across your organization and specifically your developers. So if two messages from different interactions do contain the same thing (semantically) but modeled differently, it will still end up the same way in your v3 RIM database. If you just blindly copy the message into your RIM db as you received them, it will be very hard afterwards to guarantee correct interpretation of your data.

Definition

A SMall Isolated Rim Fragment (SMIRF) is a logical data model that has the following characteristics:

1. It is a SIM, with 1 entry point. In terms of the HDF it is an 'expressed model'.
   • Note: a SMIRF-graph is not an object-graph, given that a single SMIRF is mainly transactional in nature.
2. A SMIRF only has Acts with fixed moodCodes. If one needs an Act in a different moodCode, it's a different SMIRF. A SMIRF only has Entities with a fixed determinerCode. If one needs an Entity with a different determinerCode, it's a different SMIRF.
3. An SMIRF instance is 'externally identifiable' by means of the identifier of its entry object, none of the other identifiers for other objects serve to identify an SMIRF instance. An SMIRF may contain identifiers (as references) to other SMIRFs.
4. Context has been resolved
   1. Conducted context is present in the data model
   2. Conducted context is pointed to from the data model (as a separate SMIRF, by reference (patient Id, authorId, etc.). Because there will be many Observations (in a clinical statement model) and most of them will have the same context, we do not advocate copying the context by value into each SMIRF for persistence. Instead it would be more efficient to have each SMIRF point to it's context object (which itself may be a context SMIRF) by reference.
5. An SMIRF instance will contain a fully resolved updated version of the SMIRF if update mode was used.
6. An SMIRF instance will contain a fully resolved version of objects that were included 'by reference'
   • The context determines how objects are to be identified; see issues discussed on the Object identity page. Notably for Roles some kind of agreement between creator/sender and processor/receiver has to be in place.
7. SMIRF is used as the atomic persistence model; SMIRF-instances are versioned; they are locked/read/replaced as a whole
   • In a services environment Entity-level services exist based on SMIRFs. Business services are composed of those Entity-level services.

DISCUSSION: Peter thinks of SMIRFs as being 'self contained, "safe for querying" clinical statements". Ewout doesn't have this as a requirement, he's seeking for modeling patterns. Currently a Safe SMIRF is a subset of all possible SMIRFs; or a Safe SMIRF is a composition of more granular SMIRFs.

Criteria for splitting a larger data model (DIM/SIM) in SMIRFs, i.e. criteria for the scope of SMIRFs include:

• Any association where propagation is turned off forms a boundary
• Any participation with a CMET forms a boundary
• A change of context (e.g. different subject/patient, different author)

1. From the RIMBAA 201010 Cambridge Minutes
2. Discussion about SPMs, now relabeled as SMIRFs.
   • There is a recognized problem resolving context (patient of record, author) for Clinical Statements (Observations) in a large RIM structure (like a CDA). The leaf Observations are not directly connected to their context which is defined in the root. If your database persists the entire large tree (CDA) then you may have a difficult time querying for “all Glucose Level Observations” for a given patient.
   • There is also the idea of “safety” in that if the “subject” is overridden somewhere between the “Clinical Document” root and the observation. You may interpret the Observation incorrectly.
   • If an application only persists the entire tree as it is received there are the difficulties noted above. It is difficult to run typical queries like “Select Observation WHERE code = “Glucose level” AND patientId = “12345”. The query would not only have many joins, but may not be safe.
   • Some RIMBAA implementers have addressed these problems by refactoring the large object trees before persistence. The idea is to create what we have decided to call “Small Isolated RIM Fragments” which we will refer to as SMIRFs.
   • A SMIRF will have it's context directly included (or referenced), and as such, will be a small subset of the object network which can be interpreted on it's own and would be “safe”.
   • In our discussion we agreed that it is easier to resolve context when parsing the object tree from the root to the leaves. It is more difficult to start at a leaf and resolve it's context by navigating proximately towards the root.
   • The idea of a “stack” is useful when parsing a RIM object tree and creating SMIRFs. For example, at the root of a CDA the “context object” says that the “subject is Mary Doe”.
   • While traversing the tree the “subject” may change to “the fetus of Mary Doe”. At the point where this context changes a context object with the new subject is pushed onto a stack. Any Observations that are found at this point have a reference to the new context object on the top of the stack. Later as the tree is traversed to a point proximal to where the context was changed, the context object is popped off the stack which reverts to the previous context. In this way we can create the SMIRFs while walking/parsing the tree.
   • (Rene joins the meeting)
   • Because there will be many Observations and most of them will have the same context, we do not advocate copying the context by value into each SMIRF for persistence. Instead it would be more efficient to have each SMIRF point to it's context object (which itself may be a context SMIRF) by reference.
   • Some have said that by creating and persisting SMIRFs you loose some meaning. This is true. For example a full RIM tree may indicate that the SubstanceAdministration of Insulin is related by an ActRelationship to an Observation of Diabetes by a “reasonFor” relationship.
   • A SMIRF may not persist this relationship so you could not query for “all of the medications that a patient is taking for a given diagnosis”. For this reason you may want to persist SMIRFs as well as the complete tree as received. The SMIRFs simplify (and make safer) the common queries like “all glucose measurements for a given patient”, while the persistence of the entire tree would allow for the more rare queries such as all medications indicated by a given diagnosis.
   • Another approach for the common problem of attaching context to an Observation was suggested by Graham Grieve. You could add (only in implementation not officially in HL7) a new attribute to Infrastructure Root that would act as a foreign key and allow you to link Observations to their Subjects.

Relation with DCM

Note that the boundaries in a DCM are drawn for different reasons, there might probably be an assessment scale SMIRF, while this would be used for many DCMs, so then there is clearly no 1-1 relationship. A DCM could be a template for an instance of a SIM which could be 1 or more SMIRFs.