1. Clinical templates, registries and e-terminologies from paper-based terminology systems to semantic interoperability Angelo Rossi Mori National Research Council, Rome - Italy HL7 / Vocabulary TC & CEN / TC251 / WG II

2. Contents key requisites for e-terminologies new roles for e-terminologieskey requisites for e-terminologies new roles for e-terminologies 4 kinds of e-terminologies4 kinds of e-terminologies usages, topics, actors 3 pillars for semantic interoperability3 pillars for semantic interoperability (repositories, templates, value domains)

3. Key requisites for e-terminologies support multiple usages of clinical data within information systemssupport multiple usages of clinical data within information systems build coherent "families”, each made of many specialised coding schemesbuild coherent "families”, each made of many specialised coding schemes restore continuum between content (values) and containers (data elements)restore continuum between content (values) and containers (data elements) achieve complete interoperability among applicationsachieve complete interoperability among applications

4. Co-existence and specialisation co-existence of families of coding schemes within the same information system (each scheme is conceived to satisfy a purpose)co-existence of families of coding schemes within the same information system (each scheme is conceived to satisfy a purpose) specialised coding schemes differspecialised coding schemes differ –by amount of details (e.g. classification vs nomenclature) –by kind of details (e.g. classifications with various purposes)

5. Specialisation of coding schemes each coding scheme is conceived for a precise purpose and context:each coding scheme is conceived for a precise purpose and context: –4-digit ICD statistics –LOINC orders / prescriptions –SNOMED clinical detail –CTP4 claims / reimboursement –MeSH information retrieval –...

6. 3 levels of clinical expressions the same data should be represented by the appropriate system according to the actual task and purpose unconstrained, spontaneous text (it could be either dictated or typed text, or an entry from a predefined local vocabulary)unconstrained, spontaneous text (it could be either dictated or typed text, or an entry from a predefined local vocabulary) entry of a detailed nomenclatureentry of a detailed nomenclature class (grouping conceived for a purpose)class (grouping conceived for a purpose)

7. clinical expressions in context taskterminological phrase admissionoperation for lower third rectum cancer schedulingabdominoperineal amputation of rectum reportinglow anterior resection of rectum with double stapling technique dischargeother anterior resection of rectum, ICD-9-CM 48.63 reimbours.operation for rectum cancer, DRG 147 cost anterior resection of the rectum analysis with double stapling technique quality low anterior resection of rectum without temporary assurancecolostomy and operation for lower third rectum cancer

8. Different but coherent coherence among coding schemescoherence among coding schemes –unnecessary diversity shall be removed –motivated diversity shall be fixed coherence betweencoherence between –local expressions for "private" recording, and –"public" expressions for communication and comparisons

9. Representing a statement / fact huge pre-coordinated nomenclaturehuge pre-coordinated nomenclature combinatorial nomenclature with controlled post-coordination (one code)combinatorial nomenclature with controlled post-coordination (one code) multi-axial nomenclature — without rules to produce combined expressions and codes (repeat multiple values in one field)multi-axial nomenclature — without rules to produce combined expressions and codes (repeat multiple values in one field) independent value domains for a set of related data elements (clinical template arranging multiple fields)independent value domains for a set of related data elements (clinical template arranging multiple fields)

10. New roles of e-terminology NO MORE "just labels"NO MORE "just labels" operational perspective of (clinical) data key for retrieval of operative data from master tables and knowledge baseskey for retrieval of operative data from master tables and knowledge bases –internal tables, within applications –commercial drug databases –triggers, e.g. warnings and alarms –Arden syntax, MLM and decision support –...

11. Contents key requisites for e-terminologies new roles for e-terminologieskey requisites for e-terminologies new roles for e-terminologies 4 kinds of e-terminologies4 kinds of e-terminologies usages, topics, actors 3 pillars for semantic interoperability3 pillars for semantic interoperability (repositories, templates, value domains)

12. Usages, topics, actors - 1 triggers for services within applicationstriggers for services within applications –life-cycle states (messages, workflows, activities) –names of messages and segments system developers HL7 maintains closed tables - CNE organisational & administrative parametersorganisational & administrative parameters –sex, race, religion, dietary preferences facility managers HL7 maintains reference tables - CWE

13. Usages, topics, actors - 2 clinical / communication & schedulingclinical / communication & scheduling –lab tests, document names, activity names master tables builders & users HL7 endorses adequate domains clinical / recordingclinical / recording –findings, History & Physical, –assessments, diagnoses, health issues recording professionals HL7 registers compatible domains

14. Contents key requisites for e-terminologies new roles for e-terminologieskey requisites for e-terminologies new roles for e-terminologies 4 kinds of e-terminologies4 kinds of e-terminologies usages, topics, actors 3 pillars for semantic interoperability3 pillars for semantic interoperability (repositories, templates, value domains)

15. The emerging needs satisfy needs ofsatisfy needs of –sub-communities (diabetes, cancer, ESRD) –ad-hoc information flows (e.g. CDC, HCFA) assure more flexibility of messages and documentsassure more flexibility of messages and documents maintain control over the process through registration and support databases i.e. decentralise but avoid the chaosmaintain control over the process through registration and support databases i.e. decentralise but avoid the chaos achieve “semantic interoperability”

16. 3 pillars for real interoperability The emerging strategy is based on 3 pillars: 1. data dictionaries and metadata registries, including names of observations (LOINC) 2. clinical templates 3. tables with enumerated value domains unresolved issue: how to maintain the respective databases ?

17. 1. metadata registries Simple list of data elementsSimple list of data elements with either answer-list or ranges of values (e.g. see “names for observations” in LOINC; see also XDT/Germany, ISO 11179, ASTM E1384) Integrated repositoryIntegrated repository with uniform representation of data elements Extension 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

18. RIM attribute locally registered entry HL7 registered entry elementary entry

19. we will need further steps harmonise data elements and tables across different systems/organisations facilitate assignment of actual data elements of end-users to data elements adopted by secondary users (CDC, HCFA, …) facilitate feedback from end-users to secondary users

20. 2. clinical templates to aggregate data elements from the repository (or from the RIM) into meaningful fragments i.e. building blocks to allow for flexible messages aggregates (and the related data elements) need a registration process under the control of HL7 TCs

21. examples of aggregates batteries of lab testsbatteries of lab tests blood pressure (systolic+diastolic)blood pressure (systolic+diastolic) + circumstances (patient's position, device) pathways in USAM-RIM (mood+links table)pathways in USAM-RIM (mood+links table) DICOM-SR (templates + context groups)DICOM-SR (templates + context groups) clusters in ENV 13606-2clusters in ENV 13606-2 clinical templates in HL7clinical templates in HL7 CMET in the HL7 HMD ?CMET in the HL7 HMD ?

22. a potential clinical example template name: “description of duodenoscopy” data element 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, …} …... (from “Nomenclature of Digestive Endoscopy”, OMED, 1994)

23. Example of legal requirements 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... (Belgian law of 14.08.1987) 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

24. repository entry clinical templateelementary entry

25. 3. Value domains Hundreds of explicit tables with enumerated value domains admitted values for each data element of the RIM and of the repository, considering restrictions due to clinical templates "e-terminologies in context" coordinated by HL7 vocabulary TC

26. numeric range HL vocab entry value domain elementary entry has domain  is restriction of enumerated table HL7 table external reference

27. a Cluster in CEN 13606-2 "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.”

28. kinds of Clusters (CEN 13606-2) 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.

29. battery in HL71/4 “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.

30. battery in HL72/4 "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). "

31. battery in HL73/4 "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. "

32. battery in HL74/4 "The word battery is used in this specification synonymously with the word 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.”

33. structure of a Template 1/2 GLOBAL INFORMATION -global name of the template (with code) -global interpretation or score -global purpose / criterion for aggregation -parent template (and kind of refinement) -global circumstances for the template as a whole (e.g. features of the sample, position of patient) -either pre-defined (e.g. type of sample, device) -or as slot to be instantiated (e.g. date of sampling) -common parameters that apply to each member, -either fixed (e.g. units) or variable

34. structure of a Template 2/2 INFORMATION ON MEMBERS of the template (they can be other templates) complete name of member, with code (from an agreed pre-existing coding system) value of the member (with units, if relevant) parameters that will assume a different value for each member (e.g. time of sampling for each value of a glucose tolerance test)

35. 3-speed standard process 1. usual ballot in HL7 2. registration of data elements and CMETs (and messages/docs) by Committee 3. registration of CMETs (and messages/docs) by –national affiliates –government agencies –disease networks (e.g. cancer registries, ESRD) –member organisations

36. 3 components of messages/docs data elements (+ definitions, value domains) from RIM or from a data dictionary arrangements into a message/document (+parsing rules and tools) i.e. developed according to HMD "quality", i.e. adequacy to task (all and only the needed data elements), assured by ballot or registration