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

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

3. “ 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

4. Opportunities
Data from the anaesthesia record may be an important resource for improving safety and quality of care e.g. NSQIP
Anaesthesia Information Management Systems (AIMS) represent a valuable source of such data which is typically more comprehensive in scope and more accurate than manual equivalents.
Because AIMS store data in electronic form it is potentially accessible and transferable to other systems but lack of standardisation makes this difficult in practice

5. 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.

6. 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
The primary purpose of the anaesthetic record is to be a medico-legal record of care. However, with the advent of AIMS there are major opportunities to use information from the anaesthetic record for other purposes and so there are powerful reasons to render the electronic anaesthesia record in such a way that data can be extracted and shared.

7. 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 are 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

8. 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.

9. 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 (HL7 Clinical Document Architecture). The HL7 Anesthesiology WG is working on an implementation guide in partnership with the Structured Documents WG and Healthcare Devices WG.

10. Aspects of a solution Issue
There are 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 HL7 V3 CDA based on CEN ISO/IEEE standard

11. 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 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

12. Sampling rate may be important
“With the rapid and universal adoption of pulse oximetry and other basic monitoring guidelines in the operating room, there is now a general perception that the practice of anesthesia is completely safe. Unfortunately, this is not true. While patient injuries from unrecognized hypoxemia are now very rare due to the continuous monitoring of patient oxygenation provided by pulse oximetry, patient injuries still occur. The remaining culprit responsible for patient morbidity is unrecognized cardiovascular lability-rapid swings in blood pressure (BP) to dangerously low or high levels.”
“The use of blood pressure measurements by cuff presumes that significant alterations in blood pressure occur slowly and at predictable points in the anesthetic care of a patient. Experience with continuous patient oxygenation monitoring by pulse oximetry suggests that dangerous events can occur quickly and without warning. Why should we believe that dangerous alterations in blood pressure behave differently? Gravenstein demonstrated that significant changes in blood pressure could occur in an animal model in as short an interval as 30 seconds. Continuous monitoring of blood pressure removes even this short delay in assessment.”
Swedlow DB, Continuous Blood Pressure Monitoring and Patient Safety

13. Sampling rate may be important
“This study aims to evaluate possible differences in the values obtained by automated detection of hypertension, bradycardia and arterial blood oxygen desaturation between one minute and five minute automated recordings of physiologic data. The mean arterial pressure (MAP), heart rate (HR) derived from the radial pulse, and the arterial O2 saturation read by pulse oximeter (SpO2) were sampled continually in 20 patients undergoing general anesthesia. Anesthesia was induced and maintained using the same technique in all patients. Each parameter was automatically downloaded at one and five minute intervals to separate electronic spreadsheets. Hypertension was defined as MAP greater than 120 mmHg; bradycardia as HR lower than 50 bpm, and hypoxia as SpO2 < 95%. From the data presented we conclude that the five minute recording rate does not recognize the same number of clinical events as one minute recordings. This source of error must be considered when designing systems for computerized record keeping of anesthesia charts and when interpreting the data stored in electronic databases.”
Gregorini P, Gallina A, Caporaloni M. The Internet Journal of Anesthesiology 1997; Vol1N4: Comparison of One Minute Versus Five Minute Sampling Rate of Physiologic Data

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

15. Standard Representation of the anaesthetic record

16. “ 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

17. 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.

18. Requires pre-agreement … on both
However ...
XML makes no commitment on:
Domain specific ontological vocabulary
Ontological modelling primitives
Only feasible for closed collaboration
agents in a small & stable community
pages on a small & stable intranet
Requires pre-agreement … on both
“ 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

19. 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 HL7 Anesthesiology WG
An implementation guide for clinicians and IT specialists who wish to create anesthetic records as XML douments that validate against the HL7 V3 R2 (R3) CDA schema. This includes vital signs representation consistent with the ISO standard and guidance on value sets for different elements of the record taken from relevant clinical terminologies (ISO nomenclature standard, IOTA, SNOMED CT)

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

21. HL7 V3

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

23. Example R-MIM Person Observation subject ... Person Practitioner
classCode*: <= PSN
determinerCode*: <= PSN
id: II [1..1]
name: EN [0..*]
birthTime: TS [0..*]…
Person A
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 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.
1..1 patientPerson
1..1 patient
Patient
classCode*: <= PAT
id*: II [1..1]
addr: AD [0..1]
telecom: TEL [0..*]
Observation
classCode* <= xy
moodCode* <= xy
id*: II [1..1]
...
subject
typeCode*: <= SBJ
Person
1..1 practitioner
Practitioner
classCode*: <= PRT
id*: II [1..1]
telecom: TEL [0..*]
playedBy
performer
typeCode*: <= PRF
time: IVL<TS>
scopedBy
Organization

24. XML hierarchy Prescription author subject Patient id addr telecom
Person
ClassCode*: <=PSN
determinerCode*: <=PSN
Name: EN [0..*]
birthTime: TS [0..*] …
EntryPoint id
Prescription
classCode* <=SBADM
moodCode) <=RQO
Id*: || [1..1]
Text: ED [0..1]
statusCode: CS CNE [1..1] <=active
addr
1..1 patientLivingSubject
telecom
1..1 patient
Patient
ClassCode*: <=PAT
Id*: || [1..1]
addr: AD [0..*]
Telecom: TEL [0..*] …
Person
subject
typeCode*: <=SBJ
name
1..1 assignedEntity
CMET (Assigned)
R_AssignedPerson
[identified]
COCT_MT090101
author
typeCode*: <=AUT
Time: IVL<TS>

25. HL7 CDA

26. 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.

27. 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)

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

29. CDA Example Drug administration

30. CEN ISO/IEEE 11073

31. Why x.73?
“The CEN ISO/IEEE 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 ). Springer-Verlag, London

32. Interoperability Functional Semantic
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

33. 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.

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

35. x.73 Nomenclature 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., O2, CO2, N2O, etc. and to include this level of detail in the device nomenclature is redundant.

36. 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 ) ) = = (which uniquely identifies the SpO2 monitor term

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

38. 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

39. x.73 Nomenclature Mapping to IOTA & SNOMED CT
SNOMED ID
Systematic name
Common term
Acronym
Description/Definition
Reference ID
Code
Rate | Beats | Heart | CVS
Heart rate HR
Rate of cardiac beats
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)

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

41. Conclusions
In order to facilitate / ensure interoperability with EMRs and to allow data from anesthetic records to be fully utilised for audit the pre-requisites 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 standard and the implementation of the HL7 V3 CDA-compliant anaesthesia record specification proposed by the HL7 Anesthesiology WG will support these aims

42. Uses of data from patient connected devices

43. HL7 WG GAS
“Out of cycle” meeting, London, 16th. / 17th. February

44. HL7 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

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

46. Challenges of information transfer - Devices -
Output is often specific to the device manufacturer reflecting an internal information model
Parameters may be named in different ways rather than being taken from a standard nomenclature

47. CDA Stuctures
CDA Structures
Entries

48. CDA outline structure HEADER BODY SECTION ENTRIES
<ClinicalDocument> ... <structuredBody> <section> <text>...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <referredToExternalObservation> </referredToExternalObservation> </observation> </section> <section>...</section> </structuredBody> </ClinicalDocument>
HEADER
BODY
SECTION
ENTRIES

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

50. 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-system-specific)
Renal
Resp
Skin/Tissue
Urine

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