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.
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).
- Do we need to add 'persistence models' to the HL7 methodology? What use would a software developer have of such a model?
Example #1: (based on Context Conduction of participations, there are other kinds of examples). The models above are 'models for interoperability'.
- 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.
- 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).