Clinical templates, registries and terminologies

Clinical templates, registries and terminologies Angelo Rossi Mori National Research Council, Rome - Italy HL7 / Clinical Templates SIG & CEN / TC251 / WG II

Contents • what is a clinical template ? batteries, data sets, reusable fragments of messages • 3 pillars for semantic interoperability repositories, templates, value domains • “HL7 light”: a complementary approach • decentralisation of a registration process • involvement of professionals and agencies • a common strategy for HL7 and CEN ?

what is a template ? too many legitimate perspectives and options

battery in HL7 1/5 • “battery: • a set of one or more observations • identified as by a single name and code number, • and treated as a shorthand unit • for ordering or retrieving results • of the constituent observations. … • Vital signs, electrolytes, routine admission tests, and obstetrical ultrasound are all examples.”

battery in HL7 2/5 • "Vital signs (conventionally) consist of • diastolic and systolic blood pressure, • pulse, and respiratory rate. • Electrolytes usually consist of • Na+, K+, Cl-, and HCO3-. • Routine admission tests might contain • CBC, Electrolytes, SMA12, and Urinalysis. • (Note that the elements of a battery for our purposes may also be batteries). "

battery in HL7 3/5 • "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. "

battery in HL7 4/5 • "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. "

battery in HL7 5/5 • "The word battery is used in this specification • synonymously with the words profile or panel. • The individual observation elements • within a battery may be • characteristic of a physiologic system • (e.g., liver function tests), • or many different physiologic systems.”

Crucial issues • Version 2.x provides no rules for harmonization / registration of batteries • Constituent elements of a batterymust be predefined • Need for a registry of data elements • Need for computable value domains(numeric ranges, code sets)

Example on Lab Data results • [from HL7 version 2, § 7.4.3] • OBR|1|870930010^OE|CM3562^LAB| 80004^ELECTROLYTES|… • OBX|1|ST|84295^NA||150|mmol/l|136-148|... • OBX|2|ST|84132^K+||4.5|mmol/l|3.5-5|... • OBX|3|ST|82435^CL||102|mmol/l|94-105|... • OBX|4|ST|82374^CO2||27|mmol/l|24-31|…

Option 1: master tables • the content of the "electrolytes“ template • is a set of 4 OBXs • with locally predefined names and units. • For example, stored in Master Tables • Only the template name is sent in the order • Numeric values • will be filled in at the instantiation • How can we harmonize definitions • across master tables of different organizations ?

negotiating the template • the master table approach involves • a negotiation between sender and receiver • they exchange the definition of template, • they refine it • - how to assure version identification ? • - is it safe to send only the template name in an order, without the detail on content ?

NEW: panel names in LOINC • [from LOINC, vers. June 2000, at www.regenstrief.org/loinc] • hemogram panel(code=24358-4) • panel elements = “erythrocytes; leukocytes; hematocrit; hemoglobin; MCV; MCH; MCHC; RDW” • hemogram & platelets panel (code=24317-0) • panel elements = “hemogram panel; platelets; MPV”

option 2: LOINC+ as register • first 51 panels are available • fast and reactive maintenance process • LOINC could be a good source for names and codes of templates • but description of content is text-based, i.e. • ranges are not computer-processable • value sets do not use LOINC codes • is the description “defining” the template ? • which change justifies a new template ?

Example on Medical Recordin HL7 • [from HL7 version 2, § 9.6] • 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 …

option 3: set of detailed standards • CHIEF COMPLAINT • SOURCE • PRESENT ILLNESS • … how to obtain wide consensus • on section of documents ? • see standardization initiatives in • ASTM 31.25 and • Clinical Doc. Architecture level 2 (PRA)

Systematic rules for composition • Template: “systolic blood pressure” • OBX for systolic BP • qualifiers: • patient's position • device • measurement site • the circumstances of the measurement could be: • additional OBXs • coded elements in a compositional data type • detail within a “molecular code”

option 4: combinatorial codes • the observation code for systolic BP can be either • a single “molecular code” or a combination of codes on • patient's position • device • measurement site • We must control the overlap between • terminological component of observation code • explicit RIM attributes • (rules for combinatorial codes • are managed by coding system developers)

recurring subsegments • [from ENV 12610, Medicinal product identification, • Table 5.2.2 : Trade medicinal product identifiers] • clinical template: • trade trade unique • contents: group name trade ID • 4.2.1 medicinal product • designation x x x • 4.2.8 dosage form x x • 4.2.14 route of administration x x • 4.2.6 strength x x • 4.2.11 medicinal product • batch number x

option 5: RMIM - CMET • define new (local) templates • applying the same development methodology • conceived for standard messages in HL7 • need for thousands of data elements • as (local) extensions of the RIM • need for a registry of templates ?

Schemas (e.g. BizTalk) • [from the iEHR schema, by iSoft, at www.biztalk.org] • <ElementType name="QuantifiableObs” … > • <element type="MeasurableQuantity"/> • <element type="ResultAsNumber"/> • <element type="ResultAsRange"/> • <element type="ResultAsDate"/> • <element type="ResultAsText"/> • <element type="ReferenceLimit"/> • </ElementType>

option 6: XML family • define XML labels • define their combination by measures “external” to HL7 constructs (e.g. XML schemas ?) • in Biztalk (not limited to healthcare): • meaning of labels and value sets are not described ! • no comparison of XML tags from different vendors ! • in ebXML (not limited to healthcare) : • registries ? • a specific HL7 registry with XML.org ?

Conditional templates 1/3 • [from the CDC form for Hepatitis A notification] • BASIS FOR DIAGNOSIS • CLINICAL DATA • Symptomatic ? yesno unknown • if yes, Onset date ____ • Diarrhea yes no • if yes,from ____ to ____ • Jaundiced yes no • Hospitalized yes no • Died yes no • LABORATORY TESTS ...

Conditional templates 2/3 • Diarrhea yes no if yes,from ___ to ___ • Diarrhea is a finding, with boolean values. • The above structure could be generalised as: • Template: “boolean finding with dates” • booleanFinding^LOINC^code | booleanValue • if booleanValue = “yes” • “starting date”^LOINC^2345-7 | date • “ending date”^LOINC^3456-8 | date

Conditional templates 3/3 • Template: “boolean finding with dates” • booleanFinding^LOINC^code | booleanValue • if booleanValue = ... • Refinement of template: • conditional block: “diarrhea with dates” • “diarrhea”^LOINC^1234-6 | booleanValue • if booleanValue = “yes” • “starting date”^LOINC^2345-7 | date • “ending date”^LOINC^3456-8 | date

option 7: Arden syntax • Arden syntax is the existing mechanism • for if-then rules • it is harmonized with RIM and HDF • it could be extended for this purpose • (a special mechanism • just for this kind of template …)

Clinical check list ? (… DICOM ) • [from “Nomenclature of Digestive Endoscopy”, OMED 1994] • template name: “description of duodenoscopy” • data elements 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, …} • … ...

Legal data sets ? • [from the Belgian law of 14.08.1987] • template name: “data items for nursing file” • data elements • Care of hygiene • Care of mobility • Care of elimination • Care of food • Food by probe • Specific care of the mouth • Handling emotional problem • Care for disorientated patient • ... Vital parameter registration Physical parameter registration Surveillance of tractions, plasters Withdrawal of blood Administration of medications Surveillance of drips Care for closed wound Care for open wound

option 8: Z segments • Where is the limit ? • Why clinical templates cannot extend to whole messages and Z-segments ? • Registration and harmonisation • = appropriate control by HL7 • over the Z-segments • (and over the list of allowed data elements) • large benefits to the whole HL7 community

why templates ? purposes and use cases

typology of templates 1/2 • USAM tables • e.g. role-link-role • ENCAPSULATION (terminology vs RIM) • e.g. to describe style in messages • BATTERY = set of “Acts” • sets of observations (i.e. battery) (precise description for orders and payments) • goals, outcomes • sets of procedures (e.g. clinical guidelines) • data sets (e.g. from regulatory agencies)

typology of templates 2/2 • CDA-L2 = set of sections • Clinical Document Architecture - level 2 • expected shape of a document • DICOM SR = set of sections, acts, materials, devices, … • MESSAGES = profiles, new messages ? • internal needs of an organization • needs of a specialty (e.g. cancer network) • needs of agencies (e.g. Public Health reporting) • needs of a region / country (e.g. xDT Germany)

Expressing constraints on the RIM • [from Usam manual, version 2.6, May 2000 (table 17) ] • template: “action with admitted relationships” • action • has precondition • precondition in criteria mood • has trigger • trigger in criteria mood • has contraindication • contraindication • …

Style guidelines • a) Representation using “Value” Name style: • name is generic, values are elements of a list • HLA Antigen found = {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} • … • Both styles are in use: which one should be preferred ? • clinical templates = guidelines for style ?

guidelines of practice • define local or common practice rules • [example from HL7 v2.x] • “Routine admission tests might contain • CBC, • Electrolytes • SMA12 • Urinalysis • (Note that the elements of a battery for our purposes may also be batteries).”

NO - automatic filling in of defaults • [from “The Berkshire Eagle”, May 23, 2000] • template: “normal liver” • A GP was discovered to use “templates” • for the most frequent “normal situations” , • to automatically fill in • a list of detailed default values • as if he was actually making • each individual observation • this is not our meaning of clinical template

cluster in ENV 13606 • CLUSTER: "original component complex • used to aggregate data items and/or other clusters • to represent a compound concept. • EXAMPLES. • A blood pressure measurement consisting of systolic and diastolic pressure, • a collection or closely related clinical findings, • results of a battery of laboratory investigations, • a treatment schedule consisting of several • individually specified preparations or dosages.” • (cont.)

cluster in ENV 13606 • a set of closely inter-related symptoms • (e.g. a cough productive of discoloured sputum and blood); • a single act of physical examination • which generates more than one value • (e.g. heart sounds, a blood pressure taken lying and standing); • a set of quantities constituting a single test • (e.g. a differential white cell count); • a set of entries that might often be represented in a table • (e.g. auditory evoked potentials); • a single healthcare action • that had two or more purposes or consequences.

weak vs strong templates • weak templates (organisers) • to organize information • e.g.subsections of a clinical document • see also headed sections • in ENV 13606 (EHCR - healthcare record) • strong templates (bundles) • to handle reusable aggregations • e.g set of structured data elements • see also clusters in ENV 13606

organisers • Organisers are defined by their name only. • They contain at least one organiser or one textual data element (and bundles) • Organisers provide a weak context to their content.They provoke expectations in the human users.They convey author’s perspective on data. • The expected content of an organiser (e.g. the internal structure of a document)may be predefined to guide users

bundles • Bundles are defined by their content.They identify a set of closely related items • with a ”bottom-up” process.They represent complex conceptual units. • They contain only bundles and/or ”structured” data elements (i.e. coded or quantitative data elements). • Bundles provide a strong context to their content.They set a scope for their components. • Clusters are usually predefined.

bundle organiser structured item name range textual item name text quantitative item name interval with units coded item name value domain

sharing templates need for registries ?

emerging needs in HL7 ? • refine standard messages and documents with “local” detailed constraints or refinements, e.g. to satisfy the needs of • sub-communities (diabetes, cancer, ESRD) • ad-hoc information flows (e.g. CDC, HCFA) • regional or national information flows • management of pathology networks • registries, clinical trials, sharing records • secondary uses • reporting to authorities, statistics

clinical templates: a real need ? • is there a need to reduce combinatorial alternatives and impose a common “style” ? • what is better achieved by • a-posteriori transformations ? • is there a need for control over the processthrough registration and support databases ? • (i.e. decentralise but avoid the chaos) • if communication is local, why HL7 should • introduce international rules or registries ?

my vision: need for registries • if we want to share clinical templates • across organizations, • components of templates must be registered. • all names and labels used in templates • should be stored in a registry • should be mapped to the RIM classes • should have a well defined “value set” • (how can we decentralize the register ?)

3 pillars for real interoperability • The optimal strategy is based on 3 pillars: • 1. data dictionaries and metadata registries, • including appropriate “LOINC codes” • 2. clinical templates • 3. tables with enumerated value domains • they are complementary • all 3 pillars are needed to assure a real semantic interoperability

1. Metadata registries 1/2 • A registry of data elements, between • one thousand robust data elements i.e. the attributes in the RIM • millions of user-created XML labels • Specializations of the RIM: • each data element should be explicitly • registered as a child/refinement of a RIM class, • under control of the respective HL7-TC

1. Metadata registries 2/2 • Quick solution: • Collection of data sets and lists of XML tags • with either answer-list or ranges of values • (e.g. see “names for observations” in LOINC; • see also xDT/Germany, ASTM E1384) • Optimal solution: • Integrated repository (e.g. ISO 11179) • with uniform and comparative representation • of data elements from all the sources

2. Clinical templates • to aggregate data elements from the repository • (including the RIM) into meaningful fragments • i.e. building blocks, from predefined data elements, • to produce more detailed messages, between • hundreds of balloted standard messages • millions of user-created DTD/schemas • Templates (and the related data elements) • need a process for (local) registration • under the control of HL7 TCs • a neutral language to represent templates ?

Clinical templates, registries and terminologies