HL7 Templates SIG



Assembling clinical information

Note by Angelo Rossi Mori and Fabrizio Consorti 2001-04-19

with an analysis of the examples provided by Stan Huff

Summary

In this working document we characterise a process of wrapping clinical information into a sequence of nesting constructs, from the elementary expressions to the whole record, and its storage or communication.

The goal is not to provide a universal theory on clinical information, but:

▪ to set a framework to discuss examples of different kinds of structured data that need to be represented by one or more formalisms decided by the Templates SIG

▪ to relate the fragments of clinical information to the RIM attirbutes

▪ to explore the different kinds of models involved on this topic (terminology models, information models, etc).

We initially describe a wrapping sequence that brings from a base concept to a set of statements, as a series of Russian dolls. We distinguish three major levels:

1. semantic fragments within an attribute of the information model ("encapsulation" of terminological issues)

2. representation of a clinical statement by means of attributes of the information model

3. representation of a set of clinical statements

We use the examples contained in a powerpoint presentation by Stan Huff: "A Characterization of Terminology Models, Clinical Templates, Message Models, and other kinds of Clinical Information Models".

Contents

Assembling clinical information 1

What is a clinical statement ? 2

kernel 2

status concepts 3

instantiation context 3

context about collection of information — attribution information 4

Graphical representation of the clinical statement wrappings 4

Payload = set of clinical statements 5

1. Siblings 5

2. Associated statements — clinical context 5

3. Sections 6

Transaction unit = envelope + payload 6

Graphical representation of the transaction unit 6

Analysis of Stan's examples 7

Complex dissections of the statement's terminological part 7

Terminology instance models 7

Terminology fractal models vs information models 8

Meta terminology models — Categorial structures 9

SAM, Semantic frActal Metamodel 9

Categorial structures in MoSe and CEN/TC251 9

Categorial strucutree on medical devices 9

Metamodels on LOINC 10

Statement-level clinical template 11

A bridge between terminology and the RIM 11

Context dependent ? 11

Example from ENV 14032, Clause 5. System of concepts to support nursing actions 12

Assembling multiple statements 13

Further wrapping, up to the transaction level 14

Stan's original overheads 15

What is a clinical statement ?

First of all, we must discuss the idea of "clinical statement" from a semantic perspective.

A clinical observation is a collection of heterogeneous fragments of information, e.g.

AuditoryCanalEczema

EarRegion

AssociatedSignsAndSymptoms

ClinicalSeverity

ClinicalTrend

DateOfOnset

In this document we want to characterise the different kinds of fragments, in order to understand how templates are build and how they can be represented.

The statement is the basic unit of information in a record.

A statement is build in 4 steps, by gradually appending diverse kinds of information, as russian dolls.

We can distinguish at least 4 parts, each part is made of heterogenous fragments.

statement = kernel + status concepts + instantiation information + circumstances of collection

Each part is expressed in information models by attributes and in terminology models by semantic fragments.

The attributes do not correspond exactly to the semantic fragments listed below, i.e. an attribute could involve one or more semantic fragments. The semantic fragments that belong to each part are listed below.

kernel

• base (i.e. the most significant semantic fragment of a disease, a finding,

a procedure, without their modifiers, e.g. AuditoryCanalEczema)

• features

• color

• consistency

• flexibility (of devices)

• reusability (of devices)

• spatial context

• particular body location

• particular body region

• body side

• operational context — circumstances, method, procedure ("protocol" in GEHR ?)

• "challenge" in LOINC, preparation, kind of sample

• patient position

• observation aid, device

• motivation context — purpose, to achieve

• e.g. palliative, diagnostic

• e.g. revascularisation (in a surgical procedure)

The kernel is often considered as the realm of terminology. The base is normally listed in coding systems; most coding system includes also precoordinated terminological details (i.e. modifiers, features, circumstances and purpose), but in LOINC, for examples, sometimes these additional details are represented by post-coordination.

kernel = base +terminological details

The kernel alone is an abstract concept: we don't know what is its relation with the patient.

Note that concepts are fractal, thus each semantic fragment (either base or terminological detail) can often be further decomposed in more elementary components (e.g. blood pressure = blood + pressure, AuditoryCanalEczema = eczema + auditory canal, hepatitis = liver + inflammation). We assume that the further decomposition of the semantic fragments is a topic for terminology developers, and it is not relevant for the HL7 templates.

status concepts

changing meaning

• general prefix for situations (e.g. history of, status post)

• for conditions (e.g. risk for, ruled out)

• for procedures – life cycle status (e.g. planned, ordered, cancelled, done, etc)

• object of information (e.g. relative of patient)

• uncertainty

minor modifiers

• clinical trend

• clinical severity

• chronicity

• speed of onset

• successfulness (of procedures)

The status concepts were introduced by UK-CCC (now Information Authority) and then were extracted and listed separately from the Read codes (now Clinical Terms). They were adopted by the CEN standard on EHCR (ENV 13606-2). They overlap with the mood in HL7.

The status concepts apply to the kernel as a whole, and together they make a "fully described expression", i.e. the terminological part of the statement. It is still a generic concept, but the terminological context is now explicit.

fully described expression = kernel + status concetps

The status concept can transform dramatically the meaning of the expression. In particular, a set of descriptors involve a negation (rule out, absence, not done, …), that is a big problem for terminology representation.

instantiation context

• effective age (at the time of onset/procedure)

• date of onset

• associated date time (for a procedure)

• repetition count (for a procedure)

• scale

• units + numeric value

• qualitative value

By adding the instantiation information to a fully described expression, we obtain an instantiated expression.

situated expression = fully described expression + instantiation information

Most instantiation information are not considered as a topic for terminologists.

The qualitative values are a problem, bacause there are many ways to split a situated expression into fully described expression + qualitative values, according to the purposes of the representation (in HL7 and LOINC, this problem is called "variable vs value styles").

Vocabulary and structure must be coordinated to achieve an integrated whole and consistency in messaging.

a) Representation using “Value” Name style: name is generic, values are elements of a list

HLA Antigen present = {Aw43, B27, Cw1, Dw12, ...}

b) Representation using “Variable” Name style: list of all names, values are boolean

HLA Aw43 Antigen = {Present, Absent}

HLA B27 Antigen = {Present, Absent}

Interface A (Rheumatologist view) OBX|1|CE|4821-5^HLA-B27^LN|1|G-A203^Present^SNI|

Interface B (Paternity testing) OBX|1|CE|4694-6^HLA-TYPE^LN|1|F-C4327^B27^SNI|

context about collection of information — attribution information

• collector of information (e.g. physician)

• date of collection

• location of collection

• source of information (e.g. patient)

• patient ID etc

The attribution information completes the statement and provides important information for the interpretation.

statement = situated expression + attribution information

The circumstances of collection are rarely considered as a topic for terminologists.

Usually this kind of information apply to a set of statements and is recorded only once (see below).

Graphical representation of the clinical statement wrappings

Payload = set of clinical statements

In this section we discuss how a set of clinical statements makes the payload of a document or a message.

A set of statements may show common fragments, that may be mentioned only once in the payload description, e.g.

• the sample or the device may be the same for a set of observations,

• the attribution information may be the same for a set of statements in a section

There are at least three ways to assemble multiple statements:

1. siblings = set of similar statements (e.g. battery of electrolytes)

2. associated statements = (subjective) relations between independent statements

3. a predefined sequence of sections/sentences with explicit or implicit statements

1. Siblings

In the first way a set of similar statements may be assembled according to various criteria. This topic is perhaps the most relavant for he Templates SIG. It includes all the batteries, panels, etc.

Note that a statement is usually assembling attributes from the Information Model, whereas the definition of a battery assembles types of statements, e.g. a set of LOINC codes.

• same request, multiple actions with the same sample /method / device / property

|device-dependent |e.g. same sample, multiple measurements (+ calculations) |

|purpose-dependent |e.g. battery of tests (for screening, orientation, confirmation) |

|sequence of values in a test |e.g. glucose tolerance test |

|interdependent values |e.g. set of percentages (electrophoresis, leukocytes count) |

|unique observation act |e.g. blood pressure, systolic + diastolic |

• same study product (signal, image), multiple observations/measurements

|same signal |e.g. measurements on ECG |

|same image |e.g. description of artifacts and related mesures |

• same encounter (contact, hospital stay, a GP encounter)

|same exam |e.g. Stan's vital signs + heart exam |

2. Associated statements — clinical context

In the second way a set of (subjective) relations is established between independent statements, e.g.

• reason for a procedure

• etiology

• associated signs & simptoms

• exacerbating factors

• alleviating factors

• observations vs interpretation

The associated statements often have different instantiation and attribution information.

• same decisional context (purpose / interpretation / process (propedeutic test) / problem)

|dynamic context |i.e. links to other statement influencing the interpretation |

| |statements needed/used for a decision |

| |associated statements |

3. Sections

In the third way —— there is a (pre-defined) sequence of sections or paragraphs, e.g. for imaging, something like: preparation, performance of a procedure, results, interpretations, recommandations

The relation among the statements is established by putting different statements into the same container (Section), i.e. in a static way.

• same container

|static context |i.e. chain of nested containers (sections) above a statement |

The sections may be filled in with narrative or explicit statements, as described in the definition of battery in HL7 v2.3:

"Obstetrical ultrasound is a battery made up of traditional component measurements and the impression, all of which would be returned as separate results when returned to the requestor. "

"A test involving waveform recording (such as an EKG) can be represented as a battery made up of results of many categories, including digital waveform data, labels and annotations to the data, measurements, and the impression. "

Note that in the last sentence we consider the various measurements as siblings. They make up a section. Other sections are the waveform data, or the impression.

[from HL7 version 2, § 9.6]

history & physical = chief complaint + source + present illness + …

TXA|0001|HP^history & physical|TX^text| …

OBX|1|CE|2000.40^CHIEF COMPLAINT|| ...

OBX|2|ST|2000.01^SOURCE||PATIENT ...

OBX|3|TX|2000.02^PRESENT ILLNESS| |SUDDEN ONSET OF CHEST PAIN. 2 DAYS, PTA ASSOCIATED WITH NAUSEA, VOMITING & SOB. NO RELIEF WITH ANTACIDS …

Transaction unit = envelope + payload

This topic is not within the scope of the templates SIG and is mentioned here only for completeness.

The clinical information is stored as document or database record, or exchanged as message.

The payload is stored or exchanged together with dynamic information, i.e. an envelope.

An envelope is the transaction context. It describes, for example:

| people |author / sender, receiver and their organizations |

| patient matching information |name, sex, age |

| topic and goal |kind of message / document |

| handling dates |of creation, update, transmission, arrival |

• envelope for messages = sender, receiver, patient id, kind of payload, etc

• envelope for documents = directory entry (receiving date, address of the file) + document header

• document header = author ID, attestation date, access rights, patient ID, kind of payload

Graphical representation of the transaction unit

Analysis of Stan's examples

Here we discuss the examples provided by Stan in his slides (see them in the Annex), using the framework just described above.

We also revise the Stan's framework on terminology models vs information models.

Complex dissections of the statement's terminological part

Independently of the formalism used, the examples below are based on fractal terminology models that allow to generate complex expressions by nesting suitable building blocks.

It is unlikely that such expressions are enumerated in a static nomenclature (i.e. they will be generated by the users each time they need them).

If we really need to represent systematically and process this kind of expressions, the fractal explosion will happen within one or more RIM attributes (i.e. it is considered by the information model as ONE code), it is encapsulated within terminology.

Terminology instance models

In GALEN, we called this construct a "dissection" (borrowed from Cotè in SNOMED II).

Note that we usually remain inside the statement's terminological part (kernel + status concepts).

MAIN cardiac murmur

OCCURS_DURING diastole

HAS_FEATURE high pitch

HAS_FEATURE grade III

HAS_FEATURE blowing sound

IS_ACTED_ON_BY radiation

HAS_DESTINATION part

IS_PART_OF edge

IS_PART_OF manubrium sterni

HAS_SELECTOR left

HAS_SELECTOR lower

HAS_FEATURE volume

HAS_QUANTITY maximum

HAS_LOCATION third intercostal space

[Diastolic Murmur: x]-

->(characteristic)->[high pitched]

->(grade)->[Grade III/VI]

->(characteristic)->[Blowing]

->(characteristic)->[Decrescendo]

->(loudest)->[Third Intercostal region]

->(radiates-to)->[left lower sternal border]

(defconcept x

(F-35861 High-pitched murmur &

F-35603 Grade III/VI murmur &

F-35877 Blowing murmur &

F-35852 Decrescendo murmur &

F-35700 Diastolic murmur &

(some G-C00A Site of maximal intensity

T-D3143 Third intercostal space) &

(some G-C040 Radiates to

T-D3139 Lower parasternal region)))

Terminology fractal models vs information models

Note that the information model describes which attributes are candidate to be processed as a unit by most applications.

For example we have the following attribute (from a previous release of the RIM):

In the terminology model, the level of detail can be far more granular, for usage by terminology developers or by coding assistance software. If we interpretate the class + attribute semantics into a fully explicit terminological expression, we obtain for example:

code for sensitivity of patient about confidentiality on health care activity

The terminology instance model for the above expression could be:

and the related dissection (i.e. the corresponding walk into the above terminology instance model) could be:

sensitivity

pertains to: patient

determines: confidentiality

is feature of: healthcare activity

is represented as: code

Meta terminology models — Categorial structures

SAM, Semantic frActal Metamodel

A semantic fractal metamodel describes the fragments of a complex concept that can be

• pre-coordinated into one RIM attribute under the control of terminology people (one code or a code phrase)

• post-coordinated into multiple RIM attributes, also with controlled redundancy

This kind of modelling is useful also to support discussions among terminology developers and to guide the systematisation of a coding system or nomenclature.

Meta terminology models are patterns for the terminology instance models.

We cannot enumerate the potential combinatorial expressions, but we can prepare patterns to generate them systematically.

Note that we still are inside the statement's terminological part (kernel + status concepts).

[MurmurModel]-

->(pitch)->[MurmurPitch]

->(audible intensity)->[MurmurGrade]

->(sound quality)->[MurmurQuality]

->(cyclic pattern)->[MurmurPattern]

->(loudest)->[ChestLocation]

->(radiates-to)->[ChestLocation]

Categorial structures in MoSe and CEN/TC251

This approach was used by CEN/TC251 and thus benefits of 10 years of experience in CEN:

the MoSe meta-standard, 5 categorial structures (lab properties, surgical procedures, vital signs, medical devices, nursing diagnoses amnd actions), ENV13606-2 about electronic health care record term list.

According to MoSe,

• pitch, audible intensity, sound quality, etc should be named "semantic links"

• MurmurPitch, MurmurGrade, MurmurQuality, etc should be named "semantic categories"

(hence the name "categorial structure", i.e. the structure of a field described by means of categories)

Categories, e.g. ChestLocation, may have their internal categorial structure, allowing a fractal-like nesting in the instances (dissections).

Categorial strucutree on medical devices

As an example, here is the categorial structure on medical devices (ENV 12611, simplified)

criteria related to the intended purpose

performs ,

has target , , ...

criteria related to the intrinsic features

is based on

has constituent , ...

non-systematic modifiers

has modifier , , ...

The categorial structure is complemented, in the CEN standard, by a thesaurus of descriptors:

category examples of descriptors

drainage, dilatation, scanning

respiration, circulation, vision

fracture, hernia, aneurism, polyp

patient, nurse, physician, staff

infant, newborn, adult, fetus

patient's home, hospital

supplied sterile, sterilizable

single-use, disposable, reusable

…

Metamodels on LOINC

Actually, the following LOINC model is very close to the analogous CEN standard on laboratory properties:

[observation]-

->(has_component)->[component]

->(has_property)->[property]

->(has_timing)->[timing]

->(has_system)->[system]

->(has_scale)->[scale]

->(has_method)->[method].

The meta-terminology model is a generator of instances. For example, the two following dissections represent two LOINC codes (i.e. two "Terminology instance models") according to the above meta-model:

[murmur grade (LOINC XXXX-Z) ]-

->(has_component)->[MURMUR GRADE]

->(has_property)->[AUDIBLE INTENSITY]

->(has_timing)->[POINT IN TIME]

->(has_system)->[HEART]

->(has_scale)->[ORDINAL]

->(has_method)->[AUSCULTATION].

[systolic blood pressure (LOINC 8480-6) ]-

->(has_component)->[INTRVASCULAR SYSTOLIC]

->(has_property)->[PRESSURE]

->(has_timing)->[POINT IN TIME]

->(has_system)->[ARTERIAL SYSTEM]

->(has_scale)->[QUANTITATIVE]

A more complex meta-model for LOINC was produced in Rome:

is acquired according to

is acquired under

has acquisition site ,

has spec

has means

has duration

is related to

has spec

has knowing mode

is processed by ,

has target , ,

has spec

relates to ,

has context

Statement-level clinical template

A bridge between terminology and the RIM

The following two examples are in between terminology models and information models. This kind of template goes out of the realm of terminology (out of the kernel of a statement) and involves attributes that can have an independent status in the RIM (i.e. these fragments are supposed to be independently processable by applications).

Nevertheless, we are still within ONE statement, from the clinical point of view.

[patient numeric measurement]-

->(has_observation_id)->[loinc_code]

->(has_value)->[value]

->(has_unit)->[unit_of_measure]

->(has_modifier)->[modifiers:{*}]

[systolic blood pressure measurement ]-

->(has_observation_id)->[8480-6 (SysBP)]

->(has_value)->[numeric_value]

->(has_units_of_measure)->[mmHg]

->(has_modifier)->[patient_position]

->(has_modifier)->[body_location]

->(has_modifier)->[device]

Actually, the second one is mostly represented within LOINC, with ONE code. But fragments of it could be represented by multiple attributes in the RIM.

Context dependent ?

The above examples are considered by Stan to be "context independent", as opposed to the following ones, that Stan calls "Cluster level clinical templates (context dependent)".

MedicationOrder ::= SET {

drug Drug,

dose Decimal,

route DrugRoute,

frequency DrugFrequency }

MedicationReaction ::= SET {

drug Drug,

dose Decimal OPT,

route DrugRoute OPT,

manifestation Manifestation,

reactionTime DateTime }

The interpretation of the role "drug" depends on the context (it has a different meaning respectively in the context of order and in the one of reaction).

We don't see this difference as unavoidable (in our view it depends on the representation style).

In fact the difference would disappear if in our dissections we use more explicit semanitc links / roles / relations:

MedicationOrder

acts on Drug

has intended route DrugRoute

has dosage Decimal

has ordered route DrugRoute

has frequency DrugFrequency

MedicationReaction

is reaction to Drug

has actuial dose Decimal

has actual route DrugRoute

has manifestation Manifestation

has reactionTime DateTime

Note the different kinds of routes (i.e. intended, ordered, actual), and their (fractal) indenting.

Example from ENV 14032, Clause 5. System of concepts to support nursing actions [1]

Table 4 - Synopsis of the categorial structure for nursing actions (from Subclause 5.2)

|base category |

| |

|differentiating criteria |

|semantic links |non-exhaustive examples of associate categories/associate domains |

|acts on |, including , , , , |

| |, , (see note 1, Subclause 4.3), |

| |, , , , , , |

| |, , , , |

| |nursing diagnosis with or without status qualifiers (see Subclause 4.4) |

| |nursing action with or without status qualifiers (see Subclause 5.3) |

|is associated with | with or without status qualifiers (see Subclause 5.3) |

|has beneficiary |, including , , |

|has site |, including , , |

| |(may be further qualified by: has spatial qualifier ) |

|has means |, including , , |

|has route | |

|has temporal qualifier | |

5.3 Additional status qualifiers for nursing actions

For the purpose of this standard, a statement about a nursing action should be represented in a patient record by two separate components:

a) a terminological kernel containing the nursing action proper, without reference to performer (e.g. nurse, client), activity life cycle (e.g. planned, completed), successfulness (e.g. successful, unsuccessful), frequency (e.g. at regular intervals, often) or temporal pattern (e.g. intermittent, continuous);

b) a set of status qualifiers, putting the terminological kernel in the context of a patient record.

Subclause 5.2 deals with the terminology systems that describe the terminological kernel on nursing actions.

This Subclause deals with the respective status qualifiers.

In principle, rubrics and terms about nursing actions — enumerated in a terminology system — should not refer to the status qualifiers listed in table 5, which should be instead enumerated within separate value sets. Within a patient record, the status qualifiers should appear as additional data items with respect to the data item for the nursing actions, and they should be used only for post-coordination. Developers of terminology systems should provide suitable guidelines to their users, about the mechanism to link the status qualifiers to the rubrics and terms on nursing actions.

The may have a , but this link is restricted only to associated actions, i.e. those following the “is associated with” link (see Subclause 5.2).

Table 5 – Status qualifiers that may be post-coordinated to expressions on nursing actions

|semantic links |associate categories |

|is performed by |, including , |

|has state qualifier | |

|has success qualifier | |

|has temporal qualifier |, |

Assembling multiple statements

The following two examples are called by Stan "Battery level clinical templates".

[vital_signs_battery]-

->(has_measurement)->[SystolicBP]

->(has_measurement)->[DiastolicBP]

->(has_measurement)->[HeartRate]

->(has_measurement)->[RespiratoryRate]

->(has_measurement)->[BodyTemperature]

[serum_electrolyte_battery]-

->(has_measurement)->[SerumSodium]

->(has_measurement)->[SerumPotassium]

->(has_measurement)->[SerumChloride]

->(has_measurement)->[SerumCO2]

According to our introduction, they could be called "siblings statements". In fact, they obey to the same generic pattern:

[battery]-

->(has_measurement)->[measurement:{*}]

The criterion for vital signs is the same purpose, whereas for electrolytes the criterion is the same kind of measurement.

We would put here also Stan's "Examination Model", because we don't see the criterion to distinguish it from the above examples (always the principle of fractal models …). The criterion is the same healthcare activity (i.e. the exam).

HeartExam ::= SET {

vitals VitalSigns,

rhythm HeartRhythm,

pulse PulseDescription,

pmi PMIDescription,

murmurs SET OF MurmurDescriptions }

Other examples of sets of related statements could be the following ones.

Note the difference with the examples on drug order and drug reaction:

▪ here each line is an independent statement,

▪ there each line was a fragment contributing to the whole meaning of the statement.

pregnancy and delivery data [from the C-CARE term list, deliverable D4.2, 2001]

▪ estd date of pregnancy begin

▪ estimated date of delivery

▪ fetus name

▪ fetus sex

▪ pregnancy maternal feeding

▪ pregnancy newborn feeding

▪ length of gestation

▪ gynecologic abnormalities

▪ birth method

▪ delivery anaesthesia

▪ gift cordon blood agreement

▪ delivery complications

▪ pregnancy comment

▪ no of fetuses in pregnancy

newborn birth data [from the C-CARE term list, deliverable D4.2, 2001]

▪ newborn sex

▪ newborn birth weight

▪ newborn birth length

▪ newborn head circumference

▪ newborn abnormalities

▪ newborn 1 min apgar

▪ newborn 5 min apgar

description of duodenoscopy [from “Nomenclature of Digestive Endoscopy”, OMED 1994]

data elements eaxmples for the value domain (for duodenoscopy)

▪ lumen {normal, spasm, stenosis, …}

▪ contents {blood, biliary stones, parasites, …}

▪ wall {rigid, decreased distensibility, …}

▪ mucosa {atrophic, granular, hyperemic, …}

▪ hemorrhage {mucosal bleeding, varices, …}

▪ flat lesions {aphta, infiltration, …}

▪ protrusions {papule, polyp, …}

… ...

Further wrapping, up to the transaction level

To avoid confusion, we don't discuss in detail the other examples produced by Stan on:

Utility Types,

Medical Record Model - Attribution Information,

Message Model (Attribution of communication)

because in our view they are not involving "clinical" templates.

You can see them in the Annex.

Roughly, the Medical Record Model corresponds to our payload, when the common attribution information are represented once, and the statements are thus limited to the "situated expressions".

The Message model corresponds to our transaction unit, i.e. when the attribution information is added to the payload.

Stan's original overheads

For your reference, I've put here the (reformatted) original overheads by Stan Huff.

Goal: Describe the relationships that exist among

Terminology models

– Instance terminology models

– Meta terminology models

– Reference terminologies

Information models

– Attribute models

– Batteries

– Clusters

– Message models

– Reference information models

Not process models or knowledgebases

Why?

Self preservation

– I’ve given this talk via a chalk board a dozen times

Professional groups

– Pediatricians, Nurses, Cardiologists, Ob-Gyn, …

Recognize the overlap

– Messaging standards

– Terminology

– Clinical data models, data sets, best practice

Share, division of labor, collaboration

How many slots do I send?

Interface A (atomic)

OBX|1|CE|8361-4^POSITION|1|SIT^Sitting|

OBX|2|NM|8479-8^SBP|1|138|mmHg|

Interface B (molecular)

OBX|1|NM|8459-0^SBP-Sitting|1|110|mmHg|

Where do I put the information?

Vocabulary and structure must be coordinated to achieve an integrated whole and consistency in messaging.

Interface A (Rheumatologist view)

OBX|1|CE|4821-5^HLA-B27^LN|1|G-A203^Present^SNI|

Interface B (Paternity testing)

OBX|1|CE|4694-6^HLA-TYPE^LN|1|F-C4327^B27^SNI|

Phrase from the physical exam

… high pitched, grade III/VI blowing decrescendo diastolic murmur heard best in the 3rd intercostal space which radiates to the left lower sternal border ...

Terminology Model: GRAIL Representation

CardiacMurmur which <

occursDuring Diastole

hasSignalFrequency (SignalFrequency which hasQuantity

(Level which hasMagnitude highLevel))

hasGrade (Grade which hasAbsoluteState gradeIII)

hasSoundMorphology (SoundMorphology which hasAbsoluteState blowing)

isActedOnBy (SignalRadiation which hasUniqueAssociatedDisplacement

(Displacement which isNonPartitivelyTo

(BodyRegion which <

isSpecificLinearDivisionOf (Edge which <

isSpecificSolidDivisionOf ManubriumSterni

hasLeftRightSelector leftSelection>)

hasUpperLowerSelection lowerSelection>)))

hasSignalAmplitude (SignalAmplitude which <

hasQuantity (Level which playsNumericalRole MaximumRole)

isActedOnBy (MeasuringProcess which actsSpecificallyOn

ThirdIntercostalSpace)>)>.

(from example by Jeremy Rogers and Alan Rector)

Terminology Model: GRAIL Intermediate Representation

(dissection)

MAIN cardiac murmur

OCCURS_DURING diastole

HAS_FEATURE high pitch

HAS_FEATURE grade III

HAS_FEATURE blowing sound

IS_ACTED_ON_BY radiation

HAS_DESTINATION part

IS_PART_OF edge

IS_PART_OF manubrium sterni

HAS_SELECTOR left

HAS_SELECTOR lower

HAS_FEATURE volume

HAS_QUANTITY maximum

HAS_LOCATION third intercostal space

(from example by Jeremy Rogers and Alan Rector)

Terminology Model: Conceptual graph

Terminology instance models show the relationships between aggregate expressions and more atomic terms

[Diastolic Murmur: x]-

->(characteristic)->[high pitched]

->(grade)->[Grade III/VI]

->(characteristic)->[Blowing]

->(characteristic)->[Decrescendo]

->(loudest)->[Third Intercostal region]

->(radiates-to)->[left lower sternal border]

(from example by Kent Spackman and Keith Campbell)

Terminology Model: SNOMED (KRSS)

Semantics: Does this statement describe several murmurs or one murmur?

(defconcept x

(F-35861 High-pitched murmur &

F-35603 Grade III/VI murmur &

F-35877 Blowing murmur &

F-35852 Decrescendo murmur &

F-35700 Diastolic murmur &

(some G-C00A Site of maximal intensity

T-D3143 Third intercostal space) &

(some G-C040 Radiates to

T-D3139 Lower parasternal region)))

(from example by Kent Spackman and Keith Campbell)

Meta Terminology Model

Meta terminology models are patterns for the terminology instance models

[MurmurModel]-

->(pitch)->[MurmurPitch]

->(audible intensity)->[MurmurGrade]

->(sound quality)->[MurmurQuality]

->(cyclic pattern)->[MurmurPattern]

->(loudest)->[ChestLocation]

->(radiates-to)->[ChestLocation]

A Reference Terminology Includes:

(Instance) Terminology models

– Models of a particular clinical statement

– Show the relationship between aggregate and atomic expressions

– KRSS (SNOMED) or GRAIL (GALEN) statements

Meta terminology models

– The models behind the instance models

Definitions of primitive terms

Computable relationships between terms

– Clarify meaning by context in hierarchies

Terminology Model: LOINC codes

[observation]-

->(has_component)->[component]

->(has_property)->[property]

->(has_timing)->[timing]

->(has_system)->[system]

->(has_scale)->[scale]

->(has_method)->[method].

[murmur grade (LOINC XXXX-Z) ]-

->(has_component)->[MURMUR GRADE]

->(has_property)->[AUDIBLE INTENSITY]

->(has_timing)->[POINT IN TIME]

->(has_system)->[HEART]

->(has_scale)->[ORDINAL]

->(has_method)->[AUSCULTATION].

[systolic blood pressure (LOINC 8480-6) ]-

->(has_component)->[INTRVASCULAR SYSTOLIC]

->(has_property)->[PRESSURE]

->(has_timing)->[POINT IN TIME]

->(has_system)->[ARTERIAL SYSTEM]

->(has_scale)->[QUANTITATIVE]

Measurement Attribute

An attribute level clinical template

[patient numeric measurement]-

->(has_observation_id)->[loinc_code]

->(has_value)->[value]

->(has_unit)->[unit_of_measure]

->(has_modifier)->[modifiers:{*}]

[systolic blood pressure measurement ]-

->(has_observation_id)->[8480-6 (SysBP)]

->(has_value)->[numeric_value]

->(has_units_of_measure)->[mmHg]

->(has_modifier)->[patient_position]

->(has_modifier)->[body_location]

->(has_modifier)->[device]

Battery: Thematic (but context independent)

Battery level clinical templates

[battery]-

->(has_measurement)->[measurement:{*}]

[vital_signs_battery]-

->(has_measurement)->[SystolicBP]

->(has_measurement)->[DiastolicBP]

->(has_measurement)->[HeartRate]

->(has_measurement)->[RespiratoryRate]

->(has_measurement)->[BodyTemperature]

vital signs

* who

* date and time

BP

* position

* device

systolic BP

diastolic BP

HR

RR

temp

* who

* oral/ear

[serum_electrolyte_battery]-

->(has_measurement)->[SerumSodium]

->(has_measurement)->[SerumPotassium]

->(has_measurement)->[SerumChloride]

->(has_measurement)->[SerumCO2]

Cluster: Context Dependent (using ASN.1)

Cluster level clinical templates (Categorial structures?)

MedicationOrder ::= SET {

drug Drug,

dose Decimal,

route DrugRoute,

frequency DrugFrequency }

MedicationReaction ::= SET {

drug Drug,

dose Decimal OPT,

route DrugRoute OPT,

manifestation Manifestation,

reactionTime DateTime }

Examination Model

HeartExam ::= SET {

vitals VitalSigns,

rhythm HeartRhythm,

pulse PulseDescription,

pmi PMIDescription,

murmurs SET OF MurmurDescriptions }

Utility Types

PersonId ::= SET {

name PersonName,

birthdate DateOfBirth,

idNumber SET OF IdNumber }

ClinicianId ::= SET {

name PersonName,

degree EducationDegree,

license SET OF LicenseNumber }

CareLocation ::= SET {

facility LocalCode,

floor LocalCode,

division LocalCode,

room LocalCode,

bed LocalCode }

Medical Record Model - Attribution Information

HeartExamRecord ::= SET{

patient PersonId,

examiner ClinicianId,

date/time DateTime,

location CareLocation,

exam HeartExam }

Message Model (Attribution of communication)

ClinicalMessage ::= SET {

messageType MessageCode,

sendDateTime DateTime,

sendingFacility FacilityId,

sendingApp ApplicationId,

receivingFacility FacilityId,

receivingApp FacilityId,

contents HeartExamRecord }

Purpose of a RIM

• A reference information model helps establish the meaning of the entities (objects) that participate in communication

• It describes the allowed relationships between objects

• It shows the relationship between coded attributes and vocabulary (terminology)

• It is the basis for creation of specific information models

Each coded attribute has a domain specification

Class: Patient

Description: A person who may receive, is receiving, or has received healthcare services.

Associations

– is_a_role_of (1,1) :: Person

– is_source_for (0,n) :: Specimen_sample

Attributes

– birth_order_number

– birth_dttm (from Person)

– gender_cd

Putting it all together

-----------------------

[1] the actual narrative provisions of the CEN standard were not copied here. The following extract is provided here just to give an idea of the content of the standard. The SAM is made by the entries in table 4 and in table 5, or by their representation in UML

-----------------------

transaction unit

Terminology Models

Cluster Models

Battery Models

Attribute Models

Message Models

Medical Record Models

Exam Models

Clinical Statements

Reference Information Models

Object Classes

Attributes

Relationships

Reference Terminology Models

Definitions

Hierarchies

Relationships

Reference Models

Information Models

envelope

[pic]

[pic]

payload

clinical statement

situated expression

clinical statement

fully described expression

kernel

attribution context

instantiation context

status concepts

base

terminological details

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download