Technical issues page
This page is for brainstorming some of the key technical issues. When it gets out of control, please feel free to restructure and convert to multiple pages. Please spell out any abbreviations / acronyms with first use!
We have already agreed to use the archetype formalism as the 'initial' formalism for representing shared CIMs and to develop an equivalent UML representation so that they can be represented in UML modelling environments. Making this concrete means creating a technical framework within one or more UML-based CIM modeling environments. To describe that, there are some key assumptions of the framework we need to agree on. These seem to include the following.
1. Are CIMs constraints on an RM or standalone models?
In archetype-land, CIMs (archetypes & templates) are constraints on an RM (i.e. an information model). This RM (including clinical Data types) is what provides data interoperability, and also key semantic patterns that recur in archetypes.
In the VA-UML environment, RM concepts do exist, in an abstract form, also with descendant classes representing concrete target RMs such as HL7v2, v3, CDA,...
In the R4C-UML environment, there is no explicit RM and all models are standalone. However there appear to be some implicit assumptions that might constitute a 'micoRM'.
To avoid confusion, we could call the 'RM' required for CIMI modelling a URM, or Underlying RM (i.e. an RM underlying the CIMs/archetypes). This URM is assumed to be more abstract, and to contain useful standard patterns.
JL: The line between "RM" and "style" seems fuzzy--is R4C's pattern where every attribute is a class a style or a uRM? We will certainly have a style: by that criterion, any stylistically similar set of models has a RM. Perhaps the question is where along the spectrum of abstract stylistic constraints to concrete clinical concepts will that RM fall? Or, which patterns listed below require classes explicitly modeled in an RM and which are simply ways of assembling whatever materials are available?
1a. URM assumed, what is in it?
If we assume a URM, we need to agree on what is in it.
TB: my proposal is that it contains key common patterns that are needed in numerous archetypes. In ADL/AOM thinking, these patterns are 'invariant' for the domain. For example, the model of Observation in openEHR commits to those things that have been found to make sense for every possible kind of observation.
An initial proposal for URM patterns below. The categories provide a rough guide to importance within the model foundations, or what could be understood as 'degree of indispensiblity' i.e. the 'primitives' patterns are obviously more ubiquitous that say the 'workflow' category. In terms of both adoption in software systems and development of archetypes, the table below potentially defines an approximate order of work, as well as a list of key patterns.
TB: Within the openEHR architectural approach, elements that are defined in the RM are those that are deemed to be 'invariant' across the whole health domain - in other words, model elements that are safe enough to commit to in software and databases. One of the justifications for doing this is that (whatever its weakness may be), the features of object-oriented modelling, in which the RM is expressed, are computationally very powerful. Other methods / infrastructures may choose to express some of these patterns as archetypes, or some other intermediate form of soft modelling. This a) implies that these modelling elements are not thought to be solid enough to commit to in software but also b) that it is ok to lose the computational power imparted by object modelling. Example: the History-of-events structure will lose its computability when expressed in either an archetype or terminology-like formalism.
|Data types||Generalised data types for key atomic data representation, including text, coded text, quantity, dates & times, etc||openEHR DTs, 21090 DTs, RFH (G Grieve)|
|(Classifiers?) Key concept + qualifiers + modifiers||Method of referencing terminology concept and adding context-specific information||Clinical Element Model Reference Model (CEReference20081114.pdf, page 20); Intermountain Healthcare|
|(Classifiers?) data / state / qualifier||In observation data, separate out data, patient state and qualifiers||DCM2010 ISO13972|
|Tree structure||Generalised free-form tree for containing clusters of data items, e.g. the 5+1 Apgar items, numerous microbiology result items, etc.||openEHR RM, 13606 RM, HL7 (all)|
|Participation||A pattern defining the connection between parties (people, organisations, devices) and other information.||HL7 (all), openEHR, 13606|
|Party + role + accountability||A pattern defining relationships between parties, including those that are roles played by some underlying actor.||HL7 RIM, openEHR|
|History of events||A structure containing 1..* Events, allowing data and patient state at each one, supporting intervals, point events, and math functions, e.g. ave/delta/max/min; used in Observation type||openEHR RM|
|Entry / clinical statement types||Distinguish key Entry types based on clinical / scientific problem solving process, including Observation, Evaluation, Instruction (order), Action, Admin entry, Generic (any content) entry||CIR|
|Observation: (Classifiers?) data / state / protocol (/reasoning)||In observation data, separate out data (actual datum being recorded e.g. BP) from patient state (e.g. lying, standing) and protocol (cuff type, instrument type)||openEHR RM|
|Order state machine + careflow mapping||A way of recording current state in progression through a standard state machine applying to any ‘order’, and mapping any specific careflow step to a standard state machine transition, enabling standardised querying||openEHR RM, HL7 RIM|
|Clinical process event links||A pattern for representing temporal links between related events in a clinical process||HL7 RIM Act Rel, openEHR / 13606 LINKs|
|Composition / document||An aggregation concept acting as a ‘bucket’ for information recorded by a professional at a given time for a given subject of care, supporting audit & context meta-data.||openEHR, 13606, CDA|
If we can agree on some / all of these patterns, we need to define them formally in an information model, and call it the URM.
MZ: Stan showed me a Model Driven System Stack. We could create a stack of the patterns / parts of CIMI to place them in context.
1b. What does 'constraining' mean?
The concept of 'constraint' needs to be understood the same way by everyone. The openEHR approach to constraining is as follows:
- the URM is constrained by ADL statements / AOM structures in archetypes that define specific configurations of URM objects, including specifying specific allowed type(s) (e.g. as children of a container), cardinalities, value ranges, value patterns, and references to other archetypes;
- archetypes can be subsequently constrained by other archetypes that specialise them;
- a special form of specialising archetype is a template that is used to 'fill slots' (open references) and mandate or prohibit specific model elements.
This constraining is done completely outside of the URM, which is a normal object model.
1c. No URM assumed in CIMs
The relevant problem under the R4C-UML approach is: how do we connect the CIMs to an real data model. The R4C approach performs mapping directly from the CIMs to concrete target RMs such as CDA, HL7v3, openEHR, etc.
To be described.
1d. Categories of patterns (for an URM?)
There are actually (4) different categories of patterns, that are all needed for a full working system:
|Information ("the basic information model") Classifiers||data, qualifier, state, modifier, attribution||CEM, CCM, DCM2010|
|Clinical||Assertion, Evaluation, Measurement, Administration, Procedure||CCM, HL7 Clinical Statement Pattern|
|Structure||Tree, History, Composition||openEHR, 13606, CDA|
TB: I don't think 'Tree' and 'History' qualify as being specific to EHR. It could certainly be argued that Composition is.; MZ: Changed it to "Structure".
JL: Composition: this should (or "should this?") be limited to clinical concepts. We do need some level of composition, but we should not stray from a focus on clinical representation: if we tackle documents and business processes, we'll sink. "Clinical process event link" looks like a boundary case--a place where we need to define a boundary.
There are two levels of CIMs
In the openEHR archetype architecture, there are two levels of 'models':
- __archetypes__: maximal data set, context-independent models of information about a specific topic.
- __templates__: perform model composition and element selection / removal; these are models of data sets specific to a use case or context
A simple way of understanding these levels is to think:
- Q: where would I define a __single data point, or group of medically related data points__, e.g. BP or heart rate observation? A: in an archetype, because it is common to all data, and we only want to do it once
- Q: where would I define a __clinical data set__, e.g. cardiology assessment of an arrhythmia patient? A: in a template, because it re-uses numerous 'standard' clinical bits and pieces (like BP, ECG, HR etc) and the data set is specific to the arrhythmia clinic assessment situation.
In ADL/AOM 1.5, archetypes and templates are expressed in a single common formalism that integrates features needed by both levels of modelling, and which allows specialisation, composition, and various kinds of constraining.
Experience has shown that these two levels are heavily used and needed by people building these models.
JL: again, CIMI scope: are we focused on "DCM"-like models, which sound like archetypes, or do we plan to extend scope to templates in order to model things like 'cardiology assessment'?
3. What is the role of the SNOMED CT concept model?
to be continued
JL: Seems like there are two approaches:
- Explicitly adopt SCT and use the concept model. If something is missing, extend and submit.
- Only ensure conformance to SCT model when using an SCT concept.
The more completely we adopt SCT as the concept source, the more sense (a) makes. Are there cases where that prevents us from modeling clearly? What impact would SCT quality issues have?
4. How do we want to express rules / functions / cross attribute relationships
to be continued
JL: Rules, to the extent that they take parameters from outside the immediate clinical concept, will be a centrifugal force against the atomicity of the DCM. Use cases for applying rules will be an integral part of defining how discrete they can remain.
Clinical Data Types
Datatypes are classes:
- We could model everything out of bits (we'd still need bits as a bootstrap class)
- We could move the bar up and use UML primitive types
- We could move it up further and use Harold's criterion (similar to value objects, data types have no identity: values are fungible)
- Or we could adopt an existing set of types
Whatever the UML solution, we'll need types for ADL. We might want to keep them similar.
Practically, data types are a general (not domain-specific) pallette for properties, if the style guide indicates properties.