CIMI Modelling Taskforce – Meeting Minutes
Thursday 26th July 2012 @ 20:00-22:00 UTC
Attendees
Core Members:







Linda Bird - Ministry of Health Holdings, Singapore
Stephen Chu – NEHTA, Australia
Gerard Freriks – EN13606 Association
Mike Lincoln – VA
Josh Mandel – SMArt
Mark Shafarman – HL7
Rahil Qamar Siddiqui – NHS Connecting for Health
Technical Resources:





Peter Hendler – Kaiser Permanente
Dipak Kalra – University College London
Daniel Karlsson – Linkopings University
David Moner – EN13606 Association
Galen Mulrooney, ONC (U.S.A.)
Clinical Modelling Resources:
 Heather Leslie – Ocean Informatics
 Sarah Ryan
 Hendry Wijaya – MOHHoldings, Singapore
Absentees
Core Members:




Tom Beale – Ocean Informatics (apologies)
Dave Carlson – VA (apologies)
Stan Huff – GE/Intermountain (apologies – travel)
Michael van der Zel – Results4Care & LifeLines (University Hospital Groningen) (apologies vacation)
Technical Resources:
 Grahame Grieve – Health Intersections
 Cecil Lynch – Accenture
Clinical Modelling Resource:





Anneke Goossen – Results4Care
William Goossen – Results4Care
Jay Lyle – VA (apologies)
Ian McNicoll – Ocean Informatics
Marcelo Rodrigues dos Santos – UFMG
Agenda
Individual Reports from Core Members
Other Weekly News & Updates
CEM Browser Now Available! www.clinicalelement.com
Ian McNicoll (CLUSTER.value example)
Call for Models
Wiki / Github
Demonstrations
GitHub (Josh)
[ADL workbench and UML tooling demonstrations postponed]
Reference Patterns - ENTRY
Examples (openEHR, NHS, IMH/GE, EN13606, Singapore, others?)
Granularity of Entries (vs Sections/Clusters)
Clinical Models (Heart Rate Model)
Weekly action plan
Individual Reports from Core Members











Linda Bird
Tom Beale
Dave Carlson
Stephen Chu
Stan Huff
Mike Lincoln
Rahil Qamar Siddiqui
Gerard Freriks
Josh Mandel
Mark Shafarman
Michael van der Zel
o [A.3] Wiki redesign and maintenance: Did some. Notably the start page. Discussions
via GITHUB! I think however that we should see the cimiwiki as our (& CIMI's)
landing page, all tools and resources should be reachable from there. I tried to
contact Galen for the meeting minutes, but have not heard back from him yet. I
assume for now that he will contact me if he needs help with putting them on the
wiki.
o [C.1] Organizer contribution of…. Have created a wiki page for the "Call for models"
and linked it to the page created by Thomas, which can now serve as the response
models index page.
o [C.2] Clinical Model Tooling: I have generated CIMI ADL's from UML (DCM) models.
Can that be considered tooling? For me it is. I wonder if they are any good. Found
some issues doing this. I believe they are in your list and I will try to update William
on those issues.
o [T.2] CIMI Ref Model Review: Have not yet created a wiki page for the reported
"issues". Shall I wait for the GitHub? Anyway, I can work on this when I get back.
o [T.6] Explore ... isosemantic models: I have touched base on this with a PhD
student and Ronald Cornet, we will talk about this and report back.
o [T.3 / T.7] Doc generation and AML Profile: We had a call this afternoon. Just
starting up. Dave and I will work on the profile in XMI and EA when I come back from
my holiday.
Brief Summary
Individual Reports from Core Members and Weekly Update &News




Reviewed wiki
Reviewed model status
o Models are due tomorrow
o William had asked for an extension until Monday
o Heather indicated that they had understood that only the blood pressure model was
due tomorrow; they’d need some more time to complete the remainder
o Steven pointed us to: http://dcm.nehta.org.au/ckm/
Josh demonstrated github
Linda Summarized the current usages of Reference Patterns
o Starting with Entry
o One remaining question is the level of granularity of entry.
Mark wanted to know when we expect to explore the connection to SNOMED and how the
attributes are related to each other. For example, if we have a number of attributes regarding an
observation, which one actually names the observation?
We definitely want to explore this, along with the question of the granularity of the entries, so that
is on our radar, but not scheduled yet.
Daniel suggested we also look into how HL7 deals with this, particularly whether the Act.Code is
attempting something similar. Linda asked Mark if he could present in a future meeting how HL7
does this.
Dipak asked whether this list of questions reflects real-world experience or proposed constructs
based on technical
Daniel agreed, but reminded us that the models are meant for implementation, so they must satisfy
multiple communities (clinicians, developers, etc.), so there will need to be some negotiation. The
models must be clinically correct, but must as be implementable.
VA will demonstrate some of the work they have been doing as part of Dave Carlson’s presentation
next week.
Linda would like more discussion next week on how does the openEHR model tie into the SNOMED
semantics and the granularity – especially with respect to time series.
Daniel noted that the protocol method in the openEHR mind map is bound to the top-level SNOMED
procedure hierarchy, which may lead to nonsensical combinations.
Rahil described the LRA models. The bound data element provides the binding to SNOMED; other
data elements can be unbounded. Each of the elements has an expression constraint that can hold a
SNOMED expression constraint. They use a lot of SNOMED CT linkage concepts, but not only
SNOMED, they have in-house ones as well.
Rahil then walked us through a mindmap instance diagram heartrate. Mark noted that Peter
Hendler was looking to distinguish between person role and functional role, which the mindmap
seems to have.
In 13606 the meaning is an attribute, but in openEHR the meaning is in the archetype reference
model
Josh questioned if this is an instance model, where is the constrained model. It’s not there, but Rahil
provided a URL that has the constrained model. The instance diagram is simplified.
Reference Patterns - ENTRY


Examples (Summary)
o openEHR
o Observation
o Evaluation
o Instruction
o Action
o NHS (Element)
 Observation (Finding Obs & Property Obs)
 Material entity
 Activity (Investigation, Material, General)
 Record Artefact
o Intermountain/GE
 Key, Item, Qualifier, Modifier, Attribution
 Observed, StandardLabObs, Procedure, Order, Intolerance, Allergy, Adverse
Reaction Summary, Admit/AdminDiagnosis
 Composition: Patient Encounter
o Singapore
 Activity (Procedure)
 Medication Activity (Order, Dispense, Administration)
 Laboratory Activity (Order, Results)
 Observation (Observable Entity)
 Observation Participants (e.g. Observing Clinician)
 Observation Name (isosemantic model)
 Observation Value
 Problem/Diagnosis (Clinical Finding, Event, Procedure)
o SNOMED CT
 Observable Entity, Clinical Finding, Procedure
o HL7 v3 version of models
o EN13606 Association
o VA ‘Discernibles’ (DoD/FHIM)
o Other?
Entry granularity vs Use of Sections/Clusters
Next week





Tom to demonstrate the ADL workbench and also to discuss the entry pattern
Dave to demonstrate the UML toolings
Mark to let us know whether
SNOMED-CT guest speaker to discuss the main SNOMED hierarchy
EN 13606 Association to discuss their reference patterns.
Additional Materials - Patterns:
openEHR ENTRY patterns




Observation: Instances of the OBSERVATION class record the observation of any
phenomenon or state of interest to do with the patient, including pathology results, blood
pressure readings, the family history and social circumstances as told by the patient to the
doctor, patient answers to physician questions during a physical examination, and responses
to a psychological assessment questionnaire.
Evaluation: the Opinion category covers a number of concrete concepts:
o problem/diagnosis
o risk assessment
o scenario
o goal
o recommendation
Instruction: actions to be performed in the future.
Action: the information recorded due to the execution of an Instruction by some agent.
NHS ELEMENT patterns
class extract package derived classes
UNBOUND_DATA_ELEMENT
{leaf}
constraints
{name value}
{meaning undefined}
COMPONENT_RELATIONSHIP_ELEMENT
{leaf}
BOUND_DATA_ELEMENT
constraints
{meaning is coded data}
{meaning is defined and is not null}
MATERIAL_ENTITY_ELEMENT
{leaf}
constraints
{meaning is a material}
{name value}
{value is type QTY}
{obs_time is undefined in LRA}
constraints
{name value}
{value defines dependency}
{must have exactly 2 links}
{value is coded data}
{one link to subject}
{one link to object}
{coded meaning from LRA vocab}
{meaning is defined}
RECORD_ARTEFACT_ELEMENT
{leaf}
constraints
{name value}
{meaning is a record artefact}
{value must be null}
{name value}
{meaning is a general activity procedure}




Observation
o Finding Observation
o Property Observation
Material entity
Activity
o Investigation Activity
o Material Activity
o General Activity
Record Artefact
SNOMED CT




Observable Entity
o Concepts in this hierarchy can be thought of as representing a question or
procedure which can produce an answer or a result. For instance, left ventricular
end-diastolic pressure (observable entity) could be interpreted as the question
"What is the left ventricular end diastolic pressure?" or "What is the measured left
ventricular end-diastolic pressure?"
o Observables are entities that could be used to code elements on a checklist or any
element where a value can be assigned. Color of nail (observable entity) is an
observable. Gray nails (finding) is a finding.
o One use for Observable entities in a clinical record is to code headers on a template.
For example, Gender (observable entity) could be used to code a section of a
template titled "Gender" where the user would choose "male" or "female". "Female
gender" would then constitute a finding.
Clinical Finding
o Concepts in this hierarchy represent the result of a clinical observation, assessment
or judgment, and include both normal and abnormal clinical states.
o Examples of Clinical finding concepts:
 Clear sputum (finding)
 Normal breath sounds (finding)
 Poor posture (finding)
o The Clinical finding hierarchy contains the sub-hierarchy of Disease. Concepts that
are descendatns of Disease (or disorder) are always and necessarily abnormal
clinical states. Multi-axial subtype hierarchies allow disease to be subtypes of other
disorders as well as subtypes of findings.
o Examples of Disease concepts:
 Tuberculosis (disorder)
 Non-Hodgkin's lymphoma (disorder)
Procedure (for Instruction, Action)
Procedure concepts represent activities performed in the provision of health care. This
hierarchy represents a broad variety of activities, including but not limited to, invasive
procedures (Excision of intracranial artery (procedure)), administration of medicines
(Pertussis vaccination (procedure)), imaging procedures (Ultrasonography of breast
(procedure)); education procedures (Low salt diet education (procedure)), and administrative
procedures (Medical records transfer (procedure)).
o Examples of Procedure concepts:
 Removal of ureteral catheter (procedure)
 Intravenous steroid injection (procedure)
 Irrigation of oral wound (procedure)
 Appendectomy (procedure)
Additional Materials - Models:
CEM – Heart Rate
qualifier MethodDevice methodDevice card(0..1);
qualifier BodyLocation bodyLocation card(0..1);
qualifier BodyPosition bodyPosition card(0..1);
qualifier AbnormalInterpretation abnormalInterpretation card(0..1);
qualifier DeltaFlag deltaFlag card(0..1);
qualifier ReferenceRangeNar referenceRangeNar card(0..1);
qualifier PatientPrecondition patientPrecondition card(0-M);
qualifier RelativeTemporalContext relativeTemporalContext card(0-M);
qualifier Comment comment card(0-M);
modifier Subject subject card(0..1);
attribution Observed observed card(0..1);
attribution ReportedReceived reportedReceived card(0..1);
attribution Verified verified card(0..1);
attribution Updated updated card(0..1);
constraint methodDevice.CD.code.domain (HeartRateMethodDevice_VALUESET_ECID);
constraint bodyLocation.CD.code.domain (HeartRateBodyLocation_VALUESET_ECID);
constraint bodyPosition.CD.code.domain (BodyPosition_VALUESET_ECID);
constraint abnormalInterpretation.CD.code.domain
(AbnormalInterpretationNumericNom_VALUESET_ECID);
constraint deltaFlag.CD.code.domain (DeltaFlagNumericNom_VALUESET_ECID);
constraint PQ.unit.domain (NumberRateUnits_VALUESET_ECID);
constraint PQ.unit.normal (PerMinute_ECID);
NHS Heart Rate
1) Diagnosis – An ELEMENT to represent the clinical nature of a diagnosis5. Diagnoses are decisions
about the nature of a condition arrived at as a result of a synthesis of signs, symptoms,
investigations (i.e. findings), and theoretical knowledge. Conditions that may be diagnoses
include diseases, disorders, syndromes and physiological states such as pregnancy5. The
recording of a Diagnosis should be seen as being true at a particular point in time. A Care
Professional will make a Diagnosis using the information available at that time. Diagnoses will
potentially progress over time as new information becomes available2. In common with other
finding observations, a Diagnosis Name is intended to fully represent the clinically relevant
nature of a clinical finding. It is distinguished as a diagnosis of a particular type by its link to a
Diagnosis Tag. A Diagnosis Name may be associated with more than one Diagnosis Tag(s). For
example, a provisional working diagnosis may subsequently be ascribed the status of primary
diagnosis5. 2: NPFIT-NCR-DES-0135.07 NHS Care Record Elements 5: NPFIT-FNT-TO-DPM-0931.05
SNOMED CT Bindings for Common Recording Patterns.
Link to view the Domain Model : Diagnosis. Constrained Domain Model for Discharge Summary:
Diagnosis
2) AllergyOrAdverseReactionEvent - An ELEMENT to represent a diagnosis of a known allergy or
adverse reaction1 event. An Adverse Reaction is any undesirable or unwanted consequence of a
preventative, diagnostic, or therapeutic procedure or regimen. An Allergy is an acquired
hypersensitivity caused by exposure to a particular antigen (allergen) resulting in a marked
increase in reactivity to that antigen upon subsequent exposure2. An allergic reaction to
substance, drug or food is essentially a subset of all adverse reactions. The term allergic reaction
should be used when the clinician deems the reaction to be allergic in origin. If there is
uncertainty then the term adverse reaction should be used3. 1: NPFIT-FNT-TO-DPM-0725.06 NPfIT Message Implementation Manual 7.2.02 2: NPFIT-NCR-DES-0135.07 NHS Care Record
Elements 3: NPFIT-NCR-DES-0422.06 Representation of Commonly Used Concepts in the Care
Record. NOTE: There is a separate model for recording Propensity.
Link to view the Domain Model: AllergyOrAdverseReactionEvent. Constrained Domain Model for
Discharge Summary: AllergyOrAdverseReactionEvent
3) ProblemAndIssue - An ELEMENT to represent the needs or related requirements to be resolved
or noted, and are perceived as a problem or issue by a patient, carer or a Care Professional1.
Problems and Issues do not progress; they will either be resolved or closed. Problems and Issues
differ from Diagnoses in this respect. Diagnoses progress as the understanding of them
increases. 1 NPFIT-NCR-DES-0135.07 NHS Care Record Elements.
Link to view the Domain Model: GenericProblemAndIssue. Constrained Domain Model for
Discharge Summary: CareIssues
openEHR Heart Rate