Persistence Models versus Interoperability Models

Back to RIMBAA.

This page is an initial draft, and as such it needs a lot more work. Please feel free to add your thoughts or concerns.

Summary

HL7 has the methodology in place to create 'models for interoperability'. RIMBAA implementers that deal with RIM-based persistence have to deal with 'models for persistence'. These are not the same (see example below).

Questions:

1. Do we need to add 'persistence models' to the HL7 methodology? What use would a software developer have of such a model?

Note: there are other issues (not just context conduction as used in the example below) which cause the need for the persistence model to be different from the 'model for interoperability'. Maybe a denormalization of datatypes. Maybe replacing all CMETs with their [universal] flavor. That is the subject of this issue - what are the differences bewteen the model for persistence and the model for interoperability? It's certainly not just context conduction, that's just a very intuitive initial example. Rene spronk 18:12, 13 January 2011 (UTC)

Examples

The followinge examples illustrate how the 'model for interoperability' differ from the 'model for persistence'

Templates are 'for interoperability'

Example #1: (based on Context Conduction of participations, there are other kinds of examples). The models above are 'models for interoperability'.

1. Let's assume that the SIM/R-MIM shown is a service payload model and that there are no wrappers. The instance on the wire may have, as shown above, [0..5] participations on Act, and [0..3] participations on Observation.
   • On persisting this instance, context conduction may be decomposed (as described in this issue xxx), which means that the persisted object structure has [0..5] participations on Act, and [0..8] participations on Observations.
2. The template/LIM shown above specifies a constraint on the SIM/R-MIM. It is a constraint on a 'model of interoperability', and not on the 'model for persistence'.
   • This is often ill understood within HL7 and by HL7 implementers. the template does NOT define that there will always be exactly 1 author for the Observation, because one could still inherit stuff from elsewhere in the model. If one were to query, at some later point in time, for Observations, and Observation is the only class of type Act in the response model, the query response is going to contain a maximum of 8 authors, and not a maximum of 3 as most people will be expecting.
   • If the template applies, as stated above, then the cardinality (in the model for persistence) of the author participation on Observation is [1..6] (the template constrains the [0..3] cardinality).

Discussion:

• They could be the same if you just persist and don't proces. Do we assume that the interoperable models are always processed before persisted? -- Michael
  • See Context Conduction in RIMBAA Applications: no, we're not assuming that one denormalizes the conduction prior to persisting the objects. I guess the term to use is to say that we're talking about a 'logical persistence model', quite how one implements that is another question. To me the 'logical persistence model' associated with the R-MIM of example 1 would show a fully denormalized version (with regards to context conduction). As such the persistence model (when it comes to context conduction) is a transform away from the R-MIM. Rene spronk
  • Note: there are other issues (not just context conduction as used in the example above) which cause the need for the persistence model to be different from the 'model for interoperability'. Maybe a denormalization of datatypes. Maybe replacing all CMETs with their [universal] flavor. That is the subject of this issue - what are the differences bewteen the model for persistence and the model for interoperability? It's certainly not just context conduction, that's just a very intuitive initial example. Rene spronk 18:12, 13 January 2011 (UTC)

• What if we wanted to coinstrain, at the persistence layer, that a certain observation can only have 1 author? This type of constraint can't be expressed in an XML instance that's sent over the wire.

Observations on Entities

Capturing "approximate age of a house" or "tattoos of a person" at the persistence level violates the RIM because it requires a Role to be present. Especially the 'Identified' role class (which one could add to satisfy the RIM) doesn't add anything in terms of functionality.

• This could be an example where one would callapse an 'interoperability model' into a non-RIM conform persistence model.

HXIT

The HXIT data type allows one to send a history of things as part of the interoperability model. Persisting an instance of HXIT would probably never be done as-is, one would have to transform to a persistence model. Note that HXIT effectively dictates a special role of ControlActs in the pertsistence model.

Datatypes

One could persist the HL7 v3 datatypes as-is, or one could denormalize the content and persist the denormalized content. This is the subject of an upcoming whitepaper by Grahame.