This wiki has undergone a migration to Confluence found Here
Persistence Models versus Interoperability Models
Revision as of 23:17, 12 January 2011 by Rene spronk (talk | contribs) (Created page with "category:RIMBAA Issue ==Summary== HL7 has the methodology in place to create 'models for interoperability'. RIMBAA implementers that deal with RIM-based persistence have to d...")
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:
- Do we need to add 'persistence models' to the HL7 methodology?
Example
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 defined that there will always be exactly 1 author for the Observation, because one could still inherit stuff from elsewhere in the model.
- If the template applies, as stated above, then the cardinality of the author participation on Observation is [1..6] (the template constrains the [0..3] cardinality).