Implementation of a standards-based anesthesia record compliant with

Implementation of a standards-based anesthesia record compliant with the Health Level 7 (HL 7) Clinical Document Architecture (CDA) Martin Hurrell, Terri Monk, Alan Nicol Andrew Norton, David Reich, John Walsh

Acknowledgements Thanks to: Todd Cooper , Masaaki Hirai, Melvin Reynolds, John Rhoads and Jan Wittenber (HL 7 Healthcare Devices WG) Bob Dolin and Liora Alshuler (HL 7 Stuctured Documents WG)

“ We believe that one of the most influential developments for the practice of anaesthesia in this decade will be the introduction of a national (or possibly international) standard XML Schema for computerised anaesthetic records, and that such development should be actively promoted by appropriate professional groups. ” Gardner M. , Peachey T. A Standard XML Schema for computerised anaesthetic records. Anaesthesia, 2002, 57, pp 1174 -1182

Meaningful use EHR technology is "meaningful" when it has capabilities including e-prescribing, exchanging electronic health information to improve the quality of care, having the capacity to provide clinical decision support to support practitioner order entry and submitting clinical quality measures - and other measures - as selected by the Secretary of Health and Human Services.

The anaesthetic record • Purposes and uses – – Medico-legal ‘On-line’ document for decision support Feed to the EHR Audit & research • Requirements for ‘meaningful use’ – Common record structure to identify clinical context – Common terminology: for aggregation and analysis – Common model: to enable AI applications, reasoning and decision support

AIMS in the real world – Most AIMS systems do not currently use a standard vocabulary / terminology and so the representation of information may vendor specific and / or site specific – The representation of data even within a site may not be consistent especially where free text entries are allowed – There a number of issues surrounding the comparability of automatically recorded vital signs data e. g. pre-processing etc. – Data from different systems are not organised with reference to a consistent model of the anaesthetic process

Aspects of a solution Issue AIMS systems do not currently use a standard vocabulary / terminology and so the representation of information may be site specific or even specific to individuals making effective aggregation difficult. Response Develop and promote a standard vocabulary / terminology and a data dictionary which, together, provide unambiguous definitions of the individual terms and guidance on their intended context of use.

Aspects of a solution Issue There is no standard representation for the anaesthetic record and data from different systems are not organised with reference to a consistent model of the anaesthetic process. Response Develop implementation guidelines tor the anaesthetic record that is based on an international standard (HL 7 Clinical Document Architecture). The HL 7 Anesthesiology WG is working on an implementation guide in partnership with the Structured Documents WG and Healthcare Devices WG.

Aspects of a solution Issue There a number of issues surrounding the comparability of automatically recorded vital signs data e. g. detailed information concerning provenance is unavailable, differences in sampling rates, pre-processing etc. Response Comprehensive and standardised representation in HL 7 V 3 CDA based on CEN ISO/IEEE 11073 standard

Different measurement techniques may not yield the same numbers “The objective of the study was assess the utility during anaesthesia of noninvasive continuous blood pressure measurement techniques which use intermittent oscillometric blood pressure measurement for their calibration. The assessment was performed by comparing noninvasive blood pressure with intra-arterial blood pressure. ” “Accuracy and agreement of OTBP-IBP and of OTBP-ITBP were not clinically acceptable. Correlation of dynamic behavior was lower for OTBP than for ITBP. A significant effect of site difference between calibration measurements and continuous measurements was not found. It is concluded that the approach of continuous noninvasive blood pressure measurement based on the combination of two different measurement methods, in which the continuous method is calibrated by the oscillometric method, lead to clinically unacceptable accuracy and agreement in the patient group studied. ” De Jong JR, Ros HH, De Lange JJ. Int J Clin Monit Comput. 1995 Feb; 12(1): 1 -10 Noninvasive continuous blood pressure measurement during anaesthesia: a clinical evaluation of a method commonly used in measuring devices OTBP- oscillometrically calibrated tonometric blood pressure ITBP - intra-arterial calibrated tonometric pressure IBP - intra-arterial blood pressure

APSF DDTF / IOTA Around 4, 500 specialist terms for anaeshesia - mapped to SNOMED CT

Standard Representation of the anaesthetic record

“ We believe that one of the most influential developments for the practice of anaesthesia in this decade will be the introduction of a national (or possibly international) standard XML Schema for computerised anaesthetic records, and that such development should be actively promoted by appropriate professional groups. ” Gardner M. , Peachey T. A Standard XML Schema for computerised anaesthetic records. Anaesthesia, 2002, 57, pp 1174 -1182

XML: self-defining? XML documents are human readable although depending upon the nature of the information they contain and the way in which they have been authored they may not always be easy to understand without supplementary information. A small fragment of an XML document might look like this : • • • <Anesthesiologist> <Firstname>John</Firstname> <Lastname>Jones</Lastname> </Anesthesiologist> ‘Anesthesiologist’, ‘Firstname’ and ‘Lastname’ are tags that identify XML elements The elements ‘Firstname’ and ‘Lastname’ are nested within the element ‘Anesthesiologist’ Deeper levels of nesting might be used to represent more complex structures.

However. . . XML makes no commitment on: • Domain specific ontological vocabulary Requires pre-agreement … on both • Ontological modelling primitives Only feasible for closed collaboration • agents in a small & stable community • pages on a small & stable intranet “ In reality, XML just clears away some of the syntactical distractions so that we can get down to the big problem: how we arrive at common understandings about knowledge representation” Jon Bosak

Background • Terminology: APSF DDTF /IOTA Terminology mainly built on SNOMED CT with new material submitted for inclusion in SNOMED. Authoring done using Protégé-OWL. Vital signs closely aligned with X. 73. • CDA Implementation Guide: In development by HL 7 Anesthesiology WG An implementation guide for clinicians and IT specialists who wish to create anesthetic records as XML douments that validate against the HL 7 V 3 R 2 (R 3) CDA schema. This includes vital signs representation consistent with the ISO 11073 standard and guidance on value sets for different elements of the record taken from relevant clinical terminologies (ISO 11073 nomenclature standard, IOTA, SNOMED CT)

Major elements of the record o o o o Record target (patient) Author Custodian Related documents Encompassing encounter Case information Operative Note Safety checks Vital signs Drugs, fluids Events Intra-operative investigations Notes

HL 7 V 3

RIM Core Classes Act Entity Role Referral Supply Procedure Observation Medication Financial act Living Subject Person Organization Place Health Chart Material Employee Patient Scheduled Resource Certified Practitioner Assigned Practitioner Specimen Participation Performer Author Witness Subject Destination Actrelationship Compositional Reference Succeeds Role-link Direct Authority Indirect Authority Replaces Part Backup

Example R-MIM Person A class. Code*: <= PSN determiner. Code*: <= PSN id: II [1. . 1] name: EN [0. . *] birth. Time: TS [0. . *]… Patient subject Medical History Person B Practitioner performer The green box at the top left depicts an entity ‘Person’ who is playing a role, ‘Patient’ and who participates in an act, ‘Observation’ as the ‘subject’. A second person plays the role ‘Practitioner’ and is scoped by (belongs to) an ‘Organization’ (which might be specifically 1. . 1 patient. Person identified). This person participates in the observation act as the performer of the act. Other attributes can be defined for each class to add more information and specificity to the model. Patient class. Code*: <= PAT id*: II [1. . 1] addr: AD [0. . 1] telecom: TEL [0. . *] Person played. By scoped. By Organization Practitioner class. Code*: <= PRT id*: II [1. . 1] telecom: TEL [0. . *] 1. . 1 patient subject type. Code*: <= SBJ 1. . 1 practitioner performer type. Code*: <= PRF time: IVL<TS> Observation class. Code* <= xy mood. Code* <= xy id*: II [1. . 1] . . .

XML hierarchy Prescription author subject Person Patient Class. Code*: <=PSN determiner. Code*: <=PSN Name: EN [0. . *] birth. Time: TS [0. . *] … Entry. Point Prescription 1. . 1 patient. Living. Subject 1. . 1 patient Patient Class. Code*: <=PAT Id*: || [1. . 1] addr: AD [0. . *] Telecom: TEL [0. . *] … subject type. Code*: <=SBJ 1. . 1 assigned. Entity CMET (Assigned) R_Assigned. Person [identified] COCT_MT 090101 author type. Code*: <=AUT Time: IVL<TS> class. Code* <=SBADM mood. Code) <=RQO Id*: || [1. . 1] Text: ED [0. . 1] status. Code: CS CNE [1. . 1] <=active id addr telecom Person name

HL 7 CDA

What is the CDA? The CDA is a document markup standard for the structure and semantics of exchanged "clinical documents". A clinical document is a documentation of observations and other services with the following characteristics: • • • Persistence Stewardship Potential for authentication Context Wholeness Human readability A CDA document is a defined and complete information object that can exist outside of a message, and can include text, images, sounds, and other multimedia content.

What is the CDA? The CDA Header identifies and classifies the document and provides information on: • • Authentication, Encounter Patient Provider The body contains the clinical report • CDA body structures – section, paragraph, list, table, caption – structures, including <body> can have own confidentiality, originator • CDA body entries – text, link, codes, content, images (multi-media)

CDA Release 2 Information Model Start Here Header Participants Body Doc ID &Type Context Sections/ Clinical Statements/ Extl Headings Coded Entries Refs 28

CDA Example Drug administration

CEN ISO/IEEE 11073

Why x. 73? “The CEN ISO/IEEE 11073 standards are the only coherent standards that address medical device interconnectivity and have resulted in a single set of internationally harmonized standards that (a) have been developed and adopted via clinical and technical contributions from within ISO and CEN member countries and (b) include contributions from the most significant manufacturers” Reynolds M. I. (2008) Device Interfaces. In J. Stonemetz & K. Ruskin (Eds. ), Anesthesia Informatics (pp. 109 -145). Springer-Verlag, London

Interoperability • Functional – Shared architectures, methods, frameworks and technologies CEN ISO/IEEE 11073: Domain Information Model (DIM) • Semantic – Shared data types, terminologies and coding systems CEN ISO/IEEE 11073: Nomenclature

x. 73 DIM: Medical Package The VMO is the base class for all medical-related objects in the model. It provides consistent naming and identification across the Medical Package model. The VMD object is an abstraction for a medical-related subsystem (e. g. , hardware or even pure software) of a medical device. Characteristics of this subsystem (e. g. , modes, versions) are captured in this object. At the same time, the VMD object is a container for objects representing measurement and status information. The Channel object is used for grouping Metric objects and, thus, allows hierarchical information organization. The Channel object is not mandatory for representation of Metric objects in a VMD.

x. 73 DIM: Medical Package Patient monitor BP module NIBP values as complex numeric

x. 73 Nomenclature: general aims – The purpose of the device nomenclature is to support an identification scheme for the Channel, VMD, and MDS objects of the DIM. – The system provides enough information to support the data from the Metric and Channel objects, without replicating this information. For example, in the case of an airway gas analyzer, such a device may be measuring one, two, or more gases. The exact gases measured can be divined from the Metric object of the DIM that this device will be generating, i. e. , O 2, CO 2, N 2 O, etc. and to include this level of detail in the device nomenclature is redundant.

x. 73 Nomenclature: Coding [context-free] Nomenclature Code == (Code Block number * 216 ) + [contextsensitive]Term Code, where Term Code has the range 216. Example: the context-free nomenclature code for a term in code block number 1 whose term code=4100 is equal to (( 1 * 216 ) + 4100) = 65536 + 4100 = 69636 (which uniquely identifies the Sp. O 2 monitor term

x. 73 Nomenclature Attributes Attribute Systematic, or DIM name Common term Acronym Description/ Definition Reference ID Code Description/Definition Purpose An organization of differentiating, relational descriptors A brief description of the name An abbreviated form of the name A long, or sentence, form of the name A symbolic, programmatic form of the term [Alpha]numeric identifier Formal or semiformal but human-readable derivation Human-readable identification or efficient lookup Mnemonic or parametric abbreviation Human-readable and as understandable as possible Development of application program interfaces (APIs) Human- and machineread-able and efficiently processable by machines Interpretability Presence Shall be unambiguous Mandatory Optional Should be unambiguous Shall be unambiguous Mandatory with the exception of synonyms Shall be unambiguous Shall be unique, but context-sensitive parts are permitted; see 7. 2 Mandatory

x. 73 Nomenclature Base concepts – – – – Analyzer : devices that manipulate or interpret acquired data in order to produce derivative results Calculator: devices that perform calculations upon raw or derived data Filter: physical particle or chemical filters Generator: devices that generate physical quantities such as heat, moisture, electrical activity, etc. Meter : devices that perform measurement functions on physical properties such as current, electrical potential, flow, etc. ) Monitor : devices that both acquire data and analyze it Stimulator: devices that generate physical quantities such as heat, moisture, electrical activity, etc. System: instruments that consist of transducive, analytical, and therapeutic components. An anesthesia system and most ventilators would fall into this device class

x. 73 Nomenclature Mapping to IOTA & SNOMED CT IOTA-09527977651 Systematic name Rate | Beats | Heart | CVS Common term Acronym Heart rate HR SNOMED ID 09527977651 Description/Definition Rate of cardiac beats Reference ID Code MDC_ECG_HEART_RATE 16770 An organization of differentiating, relational descriptors A symbolic, programmatic form of the term Formal or semiformal but human-readable derivation Development of application program interfaces (APIs)

Modelling • • Use Case(s) Activity Diagram(s) Glossary UML Model (X 73 and Drug Modelling, included) MDHT (Model Drive Health Tools) • Constrained CDA Model • Implementation Guide • Java Library

Conclusions In order to facilitate / ensure interoperability with EMRs and to allow data from anesthetic records to be fully utilised for audit the prerequisites are: – A standard nomenclature that fully and unambiguously describes data collected from patient-connected devices during anaesthesia – A standard way to represent the anaesthetic record that provides full contextual information that will allow data derived from devices to be analysed and interpreted correctly It is hoped that the combination of the IOTA / SNOMED CT terms for anaesthesia, the CEN ISO/IEEE 11073 standard and the implementation of the HL 7 V 3 CDA-compliant anaesthesia record specification proposed by the HL 7 Anesthesiology WG will support these aims

HL 7 WG GAS www. hl 7. org “Out of cycle” meeting, London, 16 th. / 17 th. February martinhurrell@gmail. com

HL 7 WG GAS Projects • Pre-operative assessment domain analysis model • Anesthetic record domain analysis model • CDA Implementation Guide for Anaesthetic Record including references to IHE technical framework – Proof of concept – transfer of data from MGH AIMS to US NSQIP database via generic representation

APSF DDTF / IOTA Around 4, 500 specialist terms for anaeshesia - mapped to SNOMED CT

CDA Stuctures CDA Structures Entries

CDA outline structure <Clinical. Document>. . . <structured. Body> <section> <text>. . . </text> <observation>. . . </observation> <substance. Administration> <supply>. . . </supply> </substance. Administration> <observation> <referred. To. External. Observation>. . . </referred. To. External. Observation> </observation> </section> <section>. . . </section> </structured. Body> </Clinical. Document> HEADER E N T R I E S S E C T I O N B O D Y

x. 73 Nomenclature First set of differentiating criteria Semantic link "has measured property: " Applicable descriptors include the following: – – – – – Concentration Electrical. Potential Flow Multi-Parameter Negative Pressure Rate Resistance Temperature Volume

x. 73 Nomenclature Second set of differentiating criteria Semantic link "has target: " Applicable descriptors include the following: – – – – – Airway Blood Body Brain Gas Heart Infusion Intra-Aorta Lung Multi-Gas – – – Muscle Physiologic (for devices that are very general and not body-systemspecific) Renal Resp Skin/Tissue Urine

x. 73 Nomenclature Third set of differentiating criteria Semantic link “device type: " Applicable descriptors include the following: – – Channel MDS Non-specific VMD Attributes (optional) – Acoustic – Chemical – Electrical – Impedance – Magnetic – Nuclear – Optical – Thermal