Hi Rik, Rik Smithies wrote: > > HL7 models can and commonly do have this level of granularity. > > What are generally called RMIMs perhaps typically don't, but a small "RMIM" > model could be just such a BP measurement - a component in other words. It > would generally be called a CMET or template but the model is exactly the > same despite the name. > > These components are assembled into other models (which would perhaps be > called full RMIMs, but could be other templates or CMETs), and this seems > like the assembly of archetypes into openEHR templates. > well - one of the main functions of a template is to choose what is needed from the archetypes. Let's say a template 'assembles' 5 archetypes each with (for the sake of example) 50 possible data points (note that even the BP archetype can generate 100s of data points), then the total potential number of data points is 250. But the template might choose just 10, say 2 from each archetype, according to the needs of the business process step corresponding to the data capture being modelled by the template. > > > This is obviously true to a degree since any HL7 model has a unique > validation schema that checks that an instance or a fragment conforms. > > But all models are actually expressed in the single RIM schema, since even > in instances, where you can have unique class names (eg ObservationSystolic, > ObservationDiastolic) the RIM class is indicated via structural codes eg > "classCode='OBS'". > yes, but the semantics of each such variant class are different from the parent - various attributes have been removed etc. I had all this explained to me a year ago by Gunther Sshadow in no uncertain terms - hsi explanation was that each such variant class is a 'projection' on the RIM parent class, which contains all possible attributes (aka columns) needed by that class. So any variant 'class' is actually more like the SELECT a,c,e,g part of the SQL statement SELECT a,c,e,g FROM Observation, where we assume that Observation is a table/class with columns/attributes a,b,c,d,e,f,.... Needless to say, such semantics pose all kinds of problems for object-oriented software engineering (having to know all the properties of a superclass in advance, for a start). > HL7 templates can be applied to these uniquely named classes even though the > template has different class names (in fact normally the RMIM has the > plainer names, and the graphical HL7 template the specialised ones). > > Templates are thus not tied to single RMIMs and so not to a single topic. > so a single HL7 template might only have the scope of a single (variant) class inside an RMIM?
- thomas
