Implementation of a standards-based anesthesia record compliant with the Health Level 7 (HL7) Clinical Document Architecture (CDA)

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, pp1174-1182

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

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 11073 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. 1995 Feb12(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, http//www.tensysmedical.com/News/Abs
  tract003.htm. 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 lt 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
  http//www.ispub.com/journals/IJA/Vol1N4/sampling.
  htm 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, pp1174-1182

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
• ltAnesthesiologistgt
•   ltFirstnamegtJohnlt/Firstnamegt
•   ltLastnamegtJoneslt/Lastnamegt
•   lt/Anesthesiologistgt
• 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
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 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)

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 classCode lt PSN determinerCode lt
PSN id II 1..1 name EN 0.. birthTime TS
0..
Person A
Patient
subject
Medical History
Practitioner
Person B
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 lt PAT id II 1..1 addr
AD 0..1 telecom TEL 0..
Observation classCode lt xy moodCode lt xy id
II 1..1 ...
Person
1..1 practitioner
Practitioner classCode lt PRT id II
1..1 telecom TEL 0..
playedBy
scopedBy
Organization
24
XML hierarchy
Person ClassCode ltPSN determinerCode
ltPSN Name EN 0.. birthTime TS 0..
id
Prescription classCode ltSBADM moodCode)
ltRQO Id 1..1 Text ED 0..1 statusCode
CS CNE 1..1 ltactive
addr
1..1 patientLivingSubject
telecom
1..1 patient
Person
Patient ClassCode ltPAT Id 1..1 addr AD
0.. Telecom TEL 0..
subject typeCode ltSBJ
name
1..1 assignedEntity
CMET (Assigned) R_AssignedPerson identified COCT
_MT090101
author typeCode ltAUT Time IVLltTSgt
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 ltbodygt 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
Sections/Headings
Clinical Statements/ Coded Entries
Context
Doc ID Type
Extl Refs
29
CDA Example Drug administration
30

• CEN ISO/IEEE 11073

31

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

32
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

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
35
x.73 NomenclatureNomenclature 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 ) contextsensitiveTerm Code,
where Term Code has the range 216.
Example the context-free nomenclature code for a
term in code block number 1 whose term
code4100 is equal to (( 1 216 ) 4100)
65536 4100 69636 (which uniquely identifies
the SpO2 monitor term
37
x.73 NomenclatureAttributes
Attribute 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 Should be unambiguous Optional
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 Mandatory
Reference ID A symbolic, programmatic form of the term Development of application program interfaces (APIs) Shall be unambiguous Mandatory
Code Alphanumeric identifier Human- and machine-read-able and efficiently processable by machines Shall be unique, but context-sensitive parts are permitted see 7.2 Mandatory
38
x.73 NomenclatureBase 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 NomenclatureMapping to IOTA SNOMED CT
IOTA-09527977651
SNOMED ID 09527977651
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
  11073 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
• www.hl7.org

Out of cycle meeting, London, 16th. / 17th.
February martinhurrell_at_gmail.com
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
48
CDA outline structure

• ltClinicalDocumentgt
• ...
• ltstructuredBodygt
• ltsectiongt
• lttextgt...lt/textgt
• ltobservationgt...lt/observationgt
• ltsubstanceAdministrationgt
• ltsupplygt...lt/supplygt
• lt/substanceAdministrationgt
• ltobservationgt
• ltreferredToExternalObservationgt
• ...
• lt/referredToExternalObservationgt
• lt/observationgt
• lt/sectiongt
• ltsectiongt
• ltsectiongt...lt/sectiongt
• lt/sectiongt

HEADER
BODY
SECTION
ENTRIES
49
x.73 NomenclatureFirst 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 NomenclatureSecond 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 NomenclatureThird 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