Electronic Health Records a Tutorial

1
Electronic Health Records - a Tutorial
Dr. Marco Eichelberg OFFIS - Institute for
Computer ScienceEscherweg 2, 26121 Oldenburg,
GermanyEmail eichelberg_at_offis.de
Tuncay Namlý Middle East Technical University -
SRDC06531 Ankara, TurkeyEmail
tuncay_at_srdc.metu.edu.tr
2
Introduction

• During this workshop, we will attempt to provide
  you with an overview of the state of the art in
  Electronic Health Records (EHRs).
• EHRs have been discussed in scientific literature
  for about 25 years, but the interest in this
  topic has increased significantly over last few
  years, possibly because technology (computers,
  networks etc.) is now perceived as adequate for
  practical EHR implementation.
• Electronic Health Records form an integral part
  of many current national and regional eHealth
  initiatives, includingAustria, Australia,
  Belgium, Canada, Denmark, Estonia, France,
  Germany, Hungary, Ireland, Netherlands, Norway,
  Spain, UK, USA.
• Expected benefits safer and more effective
  delivery of health care
• less medical error (better informed doctors,
  decision support systems)
• improvement of case management
• reduction of duplicate examinations
• complete correct data source for public health
  and research

3
Many Acronyms, Much Confusion...

• CCR Continuity of Care Record
• CDR Clinical Data Repository
• CMR Computerised Medical Record
• CPR Computerised Patient Record
• DMR Digital Medical Record
• EHCR Electronic Health Care Record
• EHR Electronic Health Record
• EMR Electronic Medical Record
• EPR Electronic Patient Record
• MPR Multimedia Patient Record
• PHCR Personal Health Care Record
• PHR Personal Health Record
• Is this all the same, or are we talking of
  different concepts?
• Lets better define what this workshop will be
  about...

4
Key Properties of Electronic Health Records

• Patient centered The EHR stores information
  about the health status of individually
  identified patients (citizens, customers), i.e.
  not anonymous or summarised data for public
  health / epidemiology research.
• Health related The EHR stores health related
  information, i.e. not administrative, financial
  etc. This includes data from health care, but may
  also include other health related information
  provided by the patient himself (off-the-shelf
  medicine, sports activities etc.)
• Longitudinal The EHR contains information from
  cradle to grave, i.e. is not restricted to a
  particular episode of care.
• Cross enterprise The EHR contains information
  created from different health providers (i.e.,
  more than a typical HIS system in a hospital)

5
Electronic Health Records A Definition

• An Electronic Health Record (EHR) can be
  described as a repository of information
  regarding the health of a subject of care in
  computer processable form, stored and transmitted
  securely, and accessible by multiple authorised
  users. It has a commonly agreed logical
  information model which is independent of EHR
  systems. Its primary purpose is the support of
  continuing, efficient and quality integrated
  health care and it contains information which is
  retrospective, concurrent and prospective.
• ISO/TR 205142005

6
Electronic Health Records A Definition
Deployment
Semantics

• An Electronic Health Record (EHR) can be
  described as a repository of information
  regarding the health of a subject of care in
  computer processable form, stored and transmitted
  securely, and accessible by multiple authorised
  users. It has a commonly agreed logical
  information model which is independent of EHR
  systems. Its primary purpose is the support of
  continuing, efficient and quality integrated
  health care and it contains information which is
  retrospective, concurrent and prospective.
• ISO/TR 205142005

Communication
Security
Standards
Information Models
Healthcare IT Infrastructure
7
Topics of the Day

• EHR and the Healthcare IT InfrastructureHow will
  existing systems and the EHR integrate?
• EHR Information ModelsThe shift from monolithic
  architectures to multi-level architectures using
  archetypes/templates
• EHR SemanticsPros and cons of machine-processable
  content
• EHR CommunicationGetting content "in" and "out"
• EHR StandardsBuilding blocks for EHR
  implementation
• EHR SecurityHow to tackle security and policy
  issues
• EHR DeploymentAddressing issues of volume,
  ownership and identification

8
EHR and the Healthcare IT InfrastructureA brief
look at the big picture
9
Typical Hospital IT Structure (Department View)

• Wheres the Electronic Healthcare Record?

10
EHR and Hospital IT Infrastructure

• Hospitals have been using IT intensively for many
  years - there is a typical historically grown
  IT infrastructure
• Healthcare IT is special!
• Very long lifetime of some devices (gt 20 years
  for CT, MR scanners)
• Very long archival requirements (30 years for
  certain cases in Germany)
• Heterogeneous infrastructure Many devices from
  many vendors
• High availability, loose coupling (cannot stop
  working if the HIS is down!)
• Hospital Information System The central
  administrative system
• Patient admission (creation of Patient IDs)
• Charging/billing processes
• Scheduling
• Nursing care documentation
• Electronic Patient Record (often a document
  management system for scanned paper documents)

11
EHR and Hospital IT Infrastructure

• Departmental Information System (RIS, CIS, LIS)
• Departmental scheduling
• Medical Reporting is done here!
• De-central document storage in every department
• Picture Archiving and Communication System (PACS)
• Long-term archive for digital medical images
• Specialised for large data volumes (multiple
  Terabytes per year)
• Either a departmental or a central hospital
  system (enterprise PACS)
• Cross references between scheduling and report
  data in the RISand images in the PACS exist -
  both belong together!
• All of these systems contribute somehow to the
  lifelong Electronic Health Record of a patient!

12
EHR and Hospital IT Infrastructure

• Essential question Should we replicate
  information in the EHR or just store links
  (references) to the many systems we have?
• Most HIS, RIS and PACS systems are not designed
  for access from outside world, have no
  appropriate fine-grained access rights.
• Hospitals are very hesitant to allow outside
  access to their systems which are mission
  critical and contain very sensitive information.
• However, the total data volume in healthcare is
  enormous.
• Today, hospitals in Germany that operate a PACS
  typically produce 5-10 Terabytes per year, and
  there are 2.200 hospitals - that makes up to 22
  Petabytes per year currently, and the volume is
  increasing quickly!
• Example CT technology.
• 1990 512 kB per second, about 15-25 MB per study
• 2005 96 MB per second, about 200-400 MB per
  study
• 200x 384 MB per second, multiple GBytes per
  study
• Conclusion Use distibuted data storage,
  replicate only when neccessary,and only keep
  important information in the EHR.

13
EHR Care Record vs. Longitudinal Record

• If we simply collect all health related data for
  a patient, the result might be unusable because
  of the difficulty of distinguishing relevant
  information from irrelevant information.
• It is generally recognised that we need to
  distinguish to records
• The Care Record is the collection of all data
  about an episode of care that is created at one
  healthcare institution (e.g. the electronic
  medical record).
• The Longitudinal Record is the long-term
  collection of relevant information extracted from
  multiple care records.
• The extraction of relevant information is an
  intellectual process that makes the longitudinal
  EHR useful for patient care.
• A similar extraction process already exists in
  the paper-based world
• When a patient is admitted or discharged for
  specialist care, a so-called Medical Summary is
  often exchanged between the doctors involved.
• A medical summary tries to summarise only the
  relevant information about the patients history,
  diagnoses, treatments and outcomes.
• Electronic medical summaries can thus be seen as
  a useful first step towards the EHR.

14
EHR and other e-Health Applications

• The EHR is not a value on its own - it is
  valuable when combined with care processes and IT
  applications that utilise the information
• Electronic prescribing Extract information about
  the patients current medication, allergies and
  diagnoses from the EHR and create warnings
  ifthere is a contra-indication or high risk of
  adverse drug interaction.
• Laboratory Make sure that new lab results and
  historical results from the EHR can be combined
  to show long-term trends.
• Telemedicine Make sure the EHR can be used as a
  vehicle to offer high-quality diagnostic
  services to under-served (e.g. rural) areas.
• Research and public health Make sure that
  anonymous data can be extracted automatically
  from the EHR, to enable research.
• Integrated care The EHR should serve as a means
  of synchronising the many health professionals
  involved in the treatment of patients with
  chronic diseases (diabetes, coronary heart
  disease etc.)
• Home care Integrate care provided at the
  patients home with the EHR

15
EHR and the Patient

• Since the EHR stores very personal information
  about a patient,the patient should also play a
  role in maintaining the EHR.
• Various PHCR (Personal Health Care Record)
  systems exist as commercial products that allow
  patients maintain their own personal EHR
• This shows that there is a real interest, at
  least in parts of the population
• Some essential information in any EHR can only be
  provided by the patient
• Off-the-shelf medication (which can also cause
  drug-drug interactions!)
• Sports activities (important for risk assessment)
• Finally, in many legislations the patient has a
  right to see the content of the EHR and to assign
  access rights
• Should my dentist be allowed to see my
  psychiatric record? Why?
• In an emergency situation, which types of
  documents should be available?
• Key question How can a patient access the EHR,
  especially if not computer literate?

16
EHR a System of Systems
Laws, Rules, Regulations
Patient Safety
Info Structure (Coding, Terminology, Login...)
Information Security
Healthcare Providers
Shared EHR Dossier
EHR System 1
EHR System 3
EHR System 2
Infrastructure (Internet ...)
Quality Assurance / Certification
Source Q-REC Project, Gerard Freriks
17
EHR and the Big Picture

• So far, we have asked many questions and provided
  few answers.
• We will come back to these later, but now lets
  first delve into detailsof how a comprehensive
  EHR architecture could look like...
• Information Models How information is stored
• Semantics Unambiguous representation of
  meaning
• Security How to keep the information secure
• Communication Getting content into and out of
  the EHR
• Standards Technical building blocks for a
  comprehensive EHR

18
EHR Information Models
19
Introduction What is an Information Model?

• An information model is an abstract but formal
  representation of entities including their
  properties, relationships and the operations that
  can be performed on them.
• The entities being modelled may be real-world,
  such as devices on a network, or they may
  themselves be abstract, such as the entities used
  in a billing system. Typically, though, they are
  used to model a constrained domain that can be
  completely described by a closed set of entities,
  properties, relationships and operations.
• The main driving force behind the definition of
  an information model is to provide formalism to
  the description of a problem domain without
  constraining how that description is mapped to an
  actual implementation in software. There may be
  many mappings of the information model.
• Wikipedia Information Model

20
EHR Information Models

• An EHR Information Model is an abstract model of
  that part of the world about which the EHR
  stores information
• Participants to an episode of health and their
  functional roles
• Participants Humans, organisations and
  organisational units...
• Roles Patient, referring/attending doctor,
  composer of information...
• Context of information creation
• observers involved, devices involved, language
  used etc.
• Documents and document structure
• sections, clinical statements, coded entries
• References / Links between entries
• Ownership and responsibility
• audit trail, signatures, access rights,
  sensitivity levels of information

21
EHR Information Models

• An information model is important, because
• The model determines, which types of information
  each compatible implementation of an EHR system
  has to manage (read, write, store),but not, how.
• Message formats for the exchange of EHR content
  can be derived from the model.
• Due to the longitudinal nature of an EHR, an
  information model should
• be stable over a long time, so that past, current
  and future episodes of health can be recorded in
  the same EHR
• be flexible, because medical knowledge,
  healthcare delivery processes, standards for
  best practice in clinical documentation etc.
  change over time
• Be powerful enough to cover all relevant
  information for past, current and future episodes
  of care in a single model
• be simple enough to be manageable and
  implementable!
• Isnt this the proverbial squaring the circle???

22
First Generation EHR Information ModelsExample
ENV 136062000

• ENV 136062000 was arguably the first
  implementable EHR standard
• An extension of the predecessor standard ENV
  122651995
• Information model thus called the extended
  architecture
• ENV 13606 Information Model
• Very complex model that tries to cover
  everything needed
• 90 classes in 8 subsystems
• for each class, an explicit list of data elements
  is specified
• name and description of data element
• type of data element (8 basic types including
  BLOB and Signature)
• occurrence (1, 0 or 1, 0 to many, 1 to
  many)
• Classes range from very abstract (code value,
  identifier) to very concrete (healthcare
  software, bed location)

23
Classes in ENV 136062000 Information Model

• EHCR destination
• EHCR extract
• EHCR message
• EHCR message component
• EHCR message related agent
• EHCR notification message
• EHCR source
• Healthcare agent subsystem
• address
• address data item
• attestation
• attesting agent
• bed location
• cluster
• code or string
• code value
• coded
• coded element in composite
• communicating party

• empty record component
• event data item
• expected delay
• external data reference data item
• folder
• headed section
• healthcare agent
• healthcare agent in context
• healthcare agent in context reference
• healthcare agent relationship
• healthcare agents directory
• healthcare device
• healthcare organisation
• healthcare party
• healthcare person
• healthcare software
• identifier
• language data item
• language details

• period
• person identifier data item
• person name data item
• person name details
• physical entity reference data item
• provide EHCR message
• quantifiable observation data item
• record component
• reference limit
• related date
• related healthcare agent
• related location data item
• repeat medication information
• request EHCR message
• selected component complex
• source component
• specification of EHCR information
• structured address
• structured coded data item

24
Problems with ENV 136062000 Info Model

• OK, the model is complex, but we can probably
  live with that.
• However, the model is not sufficient!
• Community Defined Data Item is an abstract
  class for a data entry in a clinical statement.
• Implementation-specific classes can be derived,
  but this requires all EHR implementations to add
  support for the community defined classes in
  their data model, otherwise they cannot process
  such content
• In the worst case this means that the database
  structure needs to be modified for each
  community defined class in each implementation!
• How do we store a blood pressure measurement in
  ENV 13606?
• The standard does not specify!
• Could be a community defined data item
• Could be a cluster with a sub-tree describing
  measurements (systolic, diastolic), values
  measured and units (mm Hg).
• Different tree shapes possible
• OK for human reader, but insufficient for
  automated processing!

25
Two-Level Modelling A Solution

• Two-Level Modelling is the solution to the basic
  problems of EHR information models, i.e.
• long-time stability vs. sufficient flexibility
• expressive power vs. sufficiently simple
  (implementable) models
• The idea is to distinguish two separate layers
  of information model
• A simple reference model that is stable over
  time, plus
• A set of constraint rules that describe how
  certain clinical concepts such as a blood
  pressure measurement, a bed location or lab
  results can be expressed in the reference model.
• These constraint rules are called Archetypes
  (OpenEHR, EHRcom) or Templates (DICOM, HL7
  CDA).
• Archetypes may change over time, but older EHR
  entries can still be stored in the same database
  because the reference model remains the same.
• A change of archetypes does not require
  structural changes in the database of EHR
  systems, because these only have to reflect the
  reference model.

26
The Archetype Principle
Diagram by Thomas Beale
27
EN 13606-1 (EHRcom) Reference Model

• Much smaller than the predecessor version
• Only high-level classes thereare no classes for
  bed location or healthcare software
• No community defined extensions to the model
• Details are added througharchetypes that define
  howconcepts like a bed location or
  healthcare software should be represented
  using classes of the reference model.

28
Archetype Definition Languages

• Archetypes/Templates are specific to the
  underlying reference model
• EHRcom archetypes cannot be used with DICOM SR
  and vice versa
• A language for the definition of archetypes is
  needed
• colloquial form human readable document
  explaining the constraint rules (HL7 CDA
  Implementation Guidelines)
• tabular form (DICOM SR Templates)
• formal programming language
• EHRcom/OpenEHR Archetype Definition Language
  (ADL)
• XML Schema and Schematron Scripts (HL7 CDA
  Implementation Guideline for German Medical
  Summary)

29
CDA Implementation Guideline
30
DICOM SR Template Measurement
31
EHRcom ADL Example Blood Count
32
Schematron Script CDA Medical Summary

• lt!-- Rules that pertain to multiple sections of
  the CDA --gt
• ltpattern name"1 Global Rules"gt
• ltrule context"/"gt
• ltassert test"cdaClinicalDocument"gt
  ltClinicalDocumentgt must be the root
  node with the namespace urnhl7-orgv3. lt/assertgt
• lt/rulegt
• lt/patterngt
• lt!-- Rules that pertain to the Author section of
  the CDA --gt
• ltpattern name"3 Author"gt
• ltrule context"cdaauthor/cdaassignedAuthor/c
  daid"gt
• ltassert test"(string-length(_at_extension)gt
  0) and (string-length(_at_root)gt0)"gt
  The ltname/gt root and extension attributes must
  be not empty. lt/assertgt
• lt/rulegt
• ltrule context"cdaClinicalDocument"gt
• ltassert test"count(cdaauthor/cdaassignedA
  uthor)1"gt There must be exactly one
  author/assignedAuthor. lt/assertgt
• lt/rulegt
• lt/patterngt

33
Archetype Libraries

• With the two-level modelling approach, the
  usability of an EHR systemcritically depends on
  the availability of suitable archetypes.
• Libraries of archetypes need to be created and
  maintained
• EHR content can be displayed without knowledge of
  the archetype,but archetypes are needed for
  machine processing of the contentand for an
  optimised display (e.g. the type of display the
  user expects)
• One advantage of the two-level modelling approach
  is that it separates technical issues
  (implementation of the reference model) from
  professional medical issues (definition of
  archetypes).
• Let the technicians implement the EHR system
  based on the ref model
• Let the domain experts define suitable archetypes
  for their domain
• The issue of ownership and responsibility for
  archetypes remains an open issue for now.
• Who is responsible for this? The standard bodies?
  The medical societies? The system vendors? The
  end users?

34
EHR Semantics
35
EHR Semantics - Introduction

• Traditionally, medical reports consist of prose
  text,sometimes extended with graphical drawings,
  tables, images.

The patient was admitted for elective invasive
study and potential interventional treatment. The
diagnostic cath procedure reveals CAD with
significant lesions within the proximal
circumflex artery and a medium-sized diagonal
branch. LV function is normal in presence of
arterial hypertension. As planned,
interventional catheter treatment is performed in
the same session, starting with the proximal
circumflex lesion, that is passed with a standard
guide wire and dilated with a 3.0mm balloon with
an acceptable result. The wire is then passed
into the obstructed diagonal branch and
dilatation is performed with a 3mm balloon, again
with an acceptable initial result. About 5 min
later, the patient develops chest pain and
anterior ST elevations. ...
36
EHR Semantics

• Lots of structured informationin this PDF file,
  but no way to ever get that out of the
  document again!

37
EHR Semantics - What do we want?

• The clinical statements in the EHR should be
  clear and unambiguous
• It should be possible to compare new data with
  prior data(i.e., extract historical data and
  display it next to the new data so that a
  comparison over time is possible)
• It should be possible to feed EHR content into a
  computer-based decision support system
• generate alarm when a new drug prescription is
  incompatible withprior drug prescriptions or
  diagnoses
• assign patient to certain risk category
• select most appropriate clinical guideline for
  patient treatment
• It should be possible to extract statistical data
  for public health and epidemiology
• Allow for data mining algorithms to search a
  large EHR database for statistically significant
  patterns, to provide data for Evidence Based
  Medicine
• All of this requires EHR content to be structured
  and machine processable (at least to a certain
  degree)!

38
The Semiotic Triangle

• Humans (as well as machines) communicate through
  the exchange of symbols (words, codes).
• A symbolic representation of an object can never
  refer directly to objects, but only through
  concepts within the mind. Therefore the link at
  the bottom of the triangle (which is a dashed
  line) is only an implied relationship
• An explicit list of concepts for a certain domain
  along with machine readable codes assigned to
  each concept is called a Controlled Vocabulary.

Thought or Reference (concept)
refers to
symbolises
Referent (object)
Symbol (code)
stands for
C. K. Ogden and I. A. Richards The Meaning of
Meaning (1923)
39
Types of Controlled Vocabularies

• Controlled Vocabulary (also Term List, Coding
  Scheme)
• List of terms that have been enumerated
  explicitly.
• List is controlled by and is available from a
  controlled vocabulary registration authority.
• All terms should have an unambiguous,
  non-redundant definition
• If the same term is commonly used to mean
  different concepts in different contexts, then
  its name is explicitly qualified to resolve this
  ambiguity.
• If multiple terms are used to mean the same
  thing, one of the terms is identified as the
  preferred term in the controlled vocabulary and
  the other terms are listed as synonyms or
  aliases.
• Taxonomy (also Classification)
• Collection of controlled vocabulary terms
  organised into a hierarchical structure. Each
  term in a taxonomy is in one or more parent-child
  (e.g. whole-part) relationships to other terms in
  the taxonomy.

Source http//www.metamodel.com/
40
Types of Controlled Vocabularies

• Thesaurus
• Networked collection of controlled vocabulary
  terms. This means that a thesaurus uses
  associative relationships in addition to
  parent-child relationships.
• Formal Ontology
• Controlled vocabulary expressed in an ontology
  representation language. This language has a
  grammar for using vocabulary terms to express
  something meaningful within a specified domain of
  interest. The grammar contains formal constraints
  (e.g., specifies what it means to be a
  well-formed statement, assertion, query, etc.) on
  how terms in the ontologys controlled vocabulary
  can be used together.

Source http//www.metamodel.com/
41
Example ENV 13606-2 Domain Term ListTerms for
Section Headings
42
Example DICOM Content Mapping ResourceCodes for
ECG Leads
43
Example SNOMED-CTCode for Bronchpneumonia
Source http//www.snomed.org/snomedct/documents/S
NOMED_CT_Components_000.pdf
44
SNOMED-CT

• SNOMED-CT (Systematized Nomenclature of Medicine
  - Clinical Terms) is a thesaurus of more than
  365,000 clinical concepts structured into the
  following hierarchies (is-a relationships)

• Clinical finding
• Procedure / intervention
• Observable entity
• Body structure
• Organism
• Substance
• Pharmaceutical / biologic product
• Specimen
• Special concept

• Physical object
• Physical force
• Events
• Environments / geographical locations
• Social context
• Context-dependent categories
• Staging and scales
• Attribute
• Qualifier value

• Descriptions Contains more than 993,420 English
  language descriptions or synonyms for flexibility
  in expressing clinical concepts
• Relationships Approximately 1.46 million
  semantic relationships to enable robust
  reliability and consistency of data retrieval

Source http//www.snomed.org/snomedct/what_is.htm
l
45
Example of a Coded Report (DICOM SR)
Concept codes describeheading of each node
46
Example of a Coded Report (DICOM SR)
Concept codes describeheading of each node
TEXT
Finding
Content codes describevalue of each node
Malignant Mass
has properties
has properties
CODE
CODE
by-reference
Finding
Finding
Malignancy
Mass
inferred from
has properties
has properties
has properties
has properties
NUM
CODE
CODE
CODE
Size
Shape
Location
Margin
15 mm
Round
Central
Irregular
47
The Coded Report, Revisited

• So, instead of storing the following block of
  text,
• we have now stored
• a graph with 7 nodes and 7 named links
• 1 block of free text malignant mass
• 1 number
• 13 machine-readable codes, taken from four
  different vocabularies
• The report is now fully machine processable
• However, which type of document can be produced
  more quickly?
• Producing a coded report manually is an enormous
  amount of work!
• Physicians operate under high workload
• The reporting physician has no immediate benefit
  from the coded report!

A mass of round shape and irregular margin, 15mm
in diameter, was found in the central region of
the breast. The mass is classified as malignant
due to the irregular margin.
48
User Acceptance the Key Issue

• Coded, machine processable reports will only find
  user acceptance
• if the users perceive a benefit from the change
  in their work process
• if the creation of the coded report is automated
  as much as possible
• with templates for each type of documents
• with intelligent applications that fill in codes
  automatically wherever possible
• with intelligent user interfaces that present
  codes in decreasing order of likeliness (most
  likely result first) based on background
  information
• with automatic creation of the human readable
  version of the report from the codes
• In general, this is an unsolved issue and an
  active research topic.
• In the meantime, we have to compromise
• Use as much structure (and background coding) as
  possible
• Use as much free text as needed for user
  acceptance and speed
• All EHR architectures support such hybrid
  documents where some, but not all content is
  coded with controlled vocabulary.

49
Example 1 Prototype GUI for Structured
Diagnostic Imaging Report
50
Example 2 Prototype GUI for StructuredUltrasound
Report
51
Prototype GUIs for Structured Reports

• Diagnostic workstation analyses context
  information encoded in the header of the
  medical images (DICOM)
• There are pre-defined lists of most probably
  diagnostic codes (ICD-10)based on
• Modality (CT, MR, X-ray, etc.)
• Body part examined (head, chest, abdomen etc.)
• Probability of codes adjusted dynamically
  Frequently used codes increase their probability,
  i.e. travel upwards on the list of codes
• In summary Clever ideas are needed in this area!

52
EHR Communication
53
EHR Communication - Introduction

• We already noted at the beginning of the tutorial
  that EHR contentis created in and managed by
  many different systems
• hospital information systems (HIS)
• departmental information systems (RIS, CIS)
• laboratory systems (LIS)
• imaging modalities, post-processing workstations
  and image archives (PACS)
• practice management systems (for the ambulatory
  sector)
• electronic prescription systems at practices,
  hospitals and pharmacies
• How do these systems interact with the EHR that
  maintains the lifelong record for a certain
  patient?
• Submission of new EHR content
• Searching for specific content within the EHR
• Requesting or retrieving content (extracts) from
  the overall EHR
• Note for medico-legal reasons one typically
  never deletes and never changes any EHR content.
  Instead, new content is submitted to the EHR and
  marked as a revised version (amendment) of
  previous content.

54
Content Submission

• When submitting new EHR content, we have to
  transmit data and metadata
• Data is the EHR content as such (e.g. set of
  documents)
• Metadata is additional data about the EHR content
  and the submission
• who is submitting (author, submitter, owner of
  the data)
• subject of the submission (patient)
• EHR content description for query purposes
• might either be derived from the EHR content
  itself
• or specified and transmitted explicitly
• data for the access rights system (who is allowed
  to retrieve this EHR content, and under which
  circumstances?)
• EHR architectures are typically patient-centric,
  i.e. each submission is assigned to exactly one
  patient, and the unique identification number of
  that patient within the EHR system (Patient ID)
  must be known to the submitter.
• IT Security measures must, of course, also be in
  place
• confidentiality, integrity, authentication, audit
  trail

55
Content Submission IHE XDS Example

• IHE XDS is an EHR standard where all metadata
  attributes must be specified explicitly during
  content submission
• submitter OID world-wide unique object
  identifier of submitter
• patient patient ID, patient demographics
• document OID world-wide unique object identifier
  for document
• author person, institution, type of institution
  (code), medical specialty, role
• document title document title
• document type codes for document type and the
  clinical acts that are documented
• document language of the document
• document confidentiality
• date/time of service and document creation
• document file format and MIME type
• relationship to predecessor version of this
  document
• cryptographic checksum to verify document
  integrity
• document status available, deprecated (replaced
  by newer version)

56
Content Query Searching in the EHR

• When accessing EHR content, we first want to
  search for specific information before retrieving
  (downloading) parts or all of the EHR content
• Where is the documentation of the patients
  current medication?
• Where can we find historical values for the
  patients blood count?
• Do we find a prior mammography study that is not
  older than 10 years?
• Who was responsible for the treatment of the
  patients diabetes in the past?
• In security terms, this problem is more complex
  than content submission!
• Which parts of the EHR is the requestor allowed
  to see?
• Should the requestor know that there is
  additional information in the EHR that he is not
  allowed to see, or should we simply conceal
  certain parts (which might be dangerous for the
  patient)?
• Who defines access rights the patient or the
  submitter of information?
• Can there be different access rights for each
  document?
• Are there different access rights for EHR content
  and metadata?

57
Content Query Searching in the EHR

• In any case, we need a query language for the
  EHR system.
• Example 1 CEN ENV 13606-4 (obsolete, not the new
  EHRcom standard)
• Requestor sends Request EHCR message specifying
• patient matching information
• reason for request (code or text)
• specification of EHR information wanted complete
  EHR, updates since ltdategt, the subset described
  by a code or text (unspecified in standard)
• EHR system returns subset of EHR in a single
  Provide EHCR message
• Example 2 IHE RID
• Requestor needs to know Patient ID of the patient
  (in the EHR system)
• Requester can query a list of documents
• filtered by rough document categories (ca. 10
  types)
• filtered by time range
• Requester can query list of medications or list
  of allergies (non-document)
• Example 3 IHE XDS
• Requestor needs to know Patient ID of the patient
  (in the EHR system)
• Requestor can send an SQL statement that is
  executed on the EHR metadata database, results
  returned in XML.
• Well-defined subset of SQL allowed, well-defined
  EHR database schema

58
Content Retrieval

• The last step downloading the selected parts of
  the EHR
• these might be located at a different place (not
  on the metadata server)
• these might be located at multiple places
• not all of these might be on-line
• Example 1 CEN ENV 13606-4 (obsolete, not the new
  EHRcom standard)
• Retrieval integrated with query (as described on
  last slide)
• Example 2 IHE RID
• (Secure) HTTP download of individual documents
  through URLs provided in query result
• Example 3 IHE XDS
• (Secure) HTTP download of individual documents
  through URL provided in the query result (XML
  file).
• Access through a Web Service (SOAP) considered as
  a future alternative

59
Content Display and Processing

• OK, we have retrieved content from the patients
  EHR, now what?
• Task 1 Display content (documents) to human
  reader
• Does not require machine processable coding of
  the content
• However, surprisingly few EHR architectures have
  a well-defined specification about how to display
  content!
• Task 2 Process content
• Create a table or graph showing the development
  of certain values over time, using measurements
  done at different times, different places, stored
  in different documents
• Feed information into decision support systems
  (medication, allergies, contraindications, risk
  assessment)
• Requires machine-processable coding of all
  content relevant for processing!
• No EHR architecture actually describes this part,
  which is left to the local clinical application,
  but makes the difference between a collection of
  dead data and an intelligent EHR that
  supports healthcare!

60
Advanced Queries

• What about advanced queries?
• Queries across multiple patient records
• Queries for public health or research questions
• Queries for data that serves as input to evidence
  based medicine
• Data mining for yet undetected patterns
• None of these are covered by the EHR
  architectures presented today!
• Need to be implemented in a proprietary way using
  direct access to the underlying database(s)
• Typical data warehousing ETL process extract,
  transform, load
• Extract retrieve those parts of the EHR database
  that are of interest
• Transform de-identify, join data from multiple
  sources, translate coded values where needed etc.
• Load load transformed data into a dedicated
  system (data warehouse) for research including
  complex queries, data mining etc.

61
EHR Standards
62
EHR Standards - Introduction

• The nice thing about standards is that there are
  so many to choose from.
• Andrew Tanenbaum, Introduction to Computer
  Networks (1980)

• In April 2006, the US National Alliance for
  Health Information Technology published a
  directory of e-Health standards, which lists
• 2104 standards related to ICT in healthcare,
  produced by
• 436 separate organisations!
• Fortunately, the list of EHR standards as such is
  much shorter. Here are the most promising
  candidates
• EHRcom CEN EN 13606 Electronic Health Record
  Communication
• CDA The HL7 Clinical Document Architecture
• DICOM SR Structured Reporting
• WADO Web Access to DICOM persistent Objects
• IHE RID Retrieve Information for Display
• IHE XDS Cross-enterprise Clinical Document
  Sharing
• MML The Medical Mark-up Language

63
EHR StandardsEHRcom - CEN/ISO 13606
64
Scope and Content of CEN/ISO 13606

• Scope a rigorous and durable information
  architecture for communicating the EHR, in order
  to support the interoperability of systems and
  components that need to interact with EHR
  services
• as discrete systems or as middleware components
• to access, transfer, add or modify health record
  entries
• via messages or distributed objects (services)
• preserving clinical meaning
• protecting confidentiality
• Content
• A generic reference model of an EHR extract
• A mechanism for representing and communicating
  the clinical organisational structure of EHRs
  archetypes
• A framework for communicating the EHR disclosure
  wishes of patients
• Interfaces between requesting and responding
  processes or systems to enable EHR communication

65
Parts of CEN EN 13606 (EHRcom)

• Part 1 Reference Model
• comprehensive, generic model for communicating
  part or all of an EHR
• Part 2 Archetype Specification
• constraint-based approach for defining clinical
  business objects that are built from the
  Reference Model - adopted from openEHR
• Part 3 Reference Archetypes and Term Lists
• initial set of archetypes mapping to other
  relevant standards
• micro-vocabularies for the Part 1 model
• Part 4 Security
• measures to support access control, consent and
  auditability of EHR communications
• Part 5 Exchange Models
• message and service interfaces to enable EHR and
  archetype communication

66
Part 1 Reference Model

• A generic information model for communicating the
  electronic health record of any one patient
• Now out for final vote in CEN
• About to be released for DIS ballot by ISO
• maps to HL7 v3, and to CDA Release 2
• maps to CEN CONTSYS concepts
• maps to CEN HISA concepts
• Hopefully a Full European Standard by Feb 2007
• Hopefully a full ISO Standard by spring 2007

67
Part 2 Archetype Interchange Specification

• A generic information model and language for
  representing and communicating the definition of
  individual instances of Archetypes
• based on the openEHR archetype specification
• comprising
• Formal requirements for representing archetypes
• UML model for representing archetypes
• Archetype Definition Language (ADL)
  representation
• Now out for final vote in CEN
• ISO WG1 has approved as a new work item

68
Part 3 Reference Term Lists and Archetypes

• A set of enumerated term lists in support of the
  other parts of this standard
• for certain attributes in Part 1
• And some Reference proto-archetypes,
• knowledge structure mappings to HL7 Acts and
  openEHR ENTRYs
• Now out for CEN Enquiry ballot
• ISO WG1 has approved as a new work item

69
Part 4 Security

• The concepts that need to be reflected within EHR
  communications to enable suitable interaction
  with the security components
• The main provisions of this Part are
• basic matrix of functional roles and Record
  Component sensitivity
• access policy communications model
• audit log summary model
• Now out for final vote in CEN
• ISO WG4 has approved as a new work item

70
Part 5 Exchange Models

• A set of interfaces and models that build on the
  other parts and can form the basis of
  message-based or service based communication
• To be published by mid 2007 by CEN
• ISO to consider this part later

71
Logical building blocks of the EHR
EHR
The electronic health record for one person
Compositions
A clinical care session, encounter or document
e.g. test result, letter
Slide courtesy of Dipak Kalra
72
Logical building blocks of the EHR
73
EHRcom Folders

• The high-level organisation of Record Components
  within an EHR Extract
• an optional hierarchy
• Folders may contain other Folders
• e.g. a Composition might be contained by more
  than one Folder
• Folders might need to be constructed specifically
  for the Extract, to help organise the
  Compositions being sent
• Folders may be attested, and marked has having a
  fixed content, if appropriate

Folder
74
EHRcom Compositions

• Corresponding to a single clinical session or
  record interaction
• corresponding to an HL7 CDA document
• The conventional unit of committal, attestation
  and revision within an EHR system
• The unit of version control within the EHR
  Extract
• the consistent building block of the Extract
• the wrapper class for additions to and revisions
  of EHR data within the Extract
• Basic medico-legal (audit) data set about a
  clinical encounter
• Care session context
• when the care activity took place
• under what legal jurisdiction (territory)
• which care facility
• as part of what service
• at which location
• Describe all of the participants in the care
  process
• Composer is optional, to cater for scanned
  documents

75
Logical building blocks of the EHR
76
EHRcom Entries
Entry

• An Entry corresponds to a single clinical
  "statement"
• May contain one or more Elements and/or one or
  more Clusters
• Represents the data structure of clinical
  observations, inferences and intended actions
• which may be simple or multi-part (lists, tables
  etc.)
• which may be time series

77
EHRcom Clusters Structured Data

• Complex entries may, for example, be
  measurements, test results or treatment
  instructions
• These may need to be represented as a list,
  table, a tree or a time series
• Some time series might have regular intervals, or
  be intermittent 'bursts"
• i.e. nested time intervals
• The data at each time point might themselves be
  complex

78
EHRcom Data Types

• The Element is the leaf node containing a single
  data value, which may be
• text
• numeric
• date/time
• person/software/agent ID
• graphical
• other MIME type e.g. image
• An Element may have a null data value
• for example if a value is not known

Element
Datavalue
79
Links between components

• Links may be required between any two record
  components
• e.g. to indicate cause and effect
• e.g. to track the evolution of orders from
  request to completion
• These might need to form linkage networks
• e.g. for clinical problems
• e.g. for clinical or service episodes

80
EHRcom Reference Model
EHR_EXTRACT
all_compositions
RECORD_COMPONENT
folders
0..
0..
compositions
FOLDER
COMPOSITION
rc_id
0..
0..
sub-folders
members
content
CONTENT
0..
0..
items
ENTRY
SECTION
0..
parts
ITEM
0..
CLUSTER
ELEMENT
value
0..1
DATA_VALUE
81
13606-1 Reference Model (final)
82
EHR StandardsCDA - the HL7 Clinical Document
Architecture
83
HL7 Clinical Document Architecture (CDA)

• The scope of the CDA is the standardization of
  clinical documents for exchange.
• A clinical document is a documentation of
  observations and other services with the
  following characteristics
• Persistence
• Stewardship
• Potential for authentication
• 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.

Slide courtesy of Fred M. Behlen and Harry Solomon
84
CDA History

• 1996 Initial discussions
• 1997 HL7 SGML SIG
• Use of Standard Generalized Markup Language for
  adding metadata to documents
• Later evolved to Extensible Markup Language (XML)
  subset of SGML
• Kona Editorial Group
• 1998 Patient Record Architecture draft
• 2000 Clinical Document Architecture Release 1
  adopted
• Limited to level 1
• 2000 SIG becomes HL7 Structured Documents
  Technical Committee
• 2005 Clinical Document Architecture Release 2
  adopted
• Expanded to levels 2 3

Slide courtesy of Fred M. Behlen and Harry Solomon
85
CDA Use Cases

• Diagnostic and therapeutic procedure reports
• Encounter / discharge summaries
• Patient history physical
• Referrals / prescriptions
• Uniform format for all clinical documents

Slide courtesy of Fred M. Behlen and Harry Solomon
86
Key Aspects of the CDA

• CDA documents are encoded in Extensible Markup
  Language (XML)
• CDA documents derive their meaning from the HL7
  Reference Information Model (RIM ) and use HL7 V3
  data types
• A CDA document consists of a header and a body
• Header is consistent across all clinical
  documents - identifies and classifies the
  document, provides information on patient,
  provider, encounter, and authentication
• Body contains narrative text / multimedia content
  (level 1), optionally augmented by coded
  equivalents (levels 2 3)

Slide courtesy of Fred M. Behlen and Harry Solomon
87
CDA Standard

• Release 1 (2000)
• Standalone standard
• Based on draft v3 RIM
• Level 1 narrative and multimedia
• Release 2 (2005)
• Incorporated into HL7 v3 Standard (Normative
  Edition just published on CD)
• Level 2 narrative and multimedia, plus coded
  statements
• Implementation Guide for Care Record Summaries,
  US Realm (currently in ballot)

Slide courtesy of Fred M. Behlen and Harry Solomon
88
CDA Release 2 Information Model
Header
Body
Start Here
Participants
Sections/Headings
Clinical Statements/ Coded Entries
Extl Refs
Context
ID/ Type
Slide courtesy of Fred M. Behlen and Harry Solomon
89
CDA Structured Body

• Arrows are Act Relationships
• Has component, Derived from, etc.
• Entries are coded clinical statements
• Observation, Procedure, Substance
  administration, etc.

Structured Body
Section Text
Section Text
Section Text
Section Text
Section Text
Section Text
Entry Coded statement
Entry Coded statement
Entry Coded statement
Slide courtesy of Fred M. Behlen and Harry Solomon
90
Clinical Document Characteristics

• Persistence
• Documents exist over time and can be used in many
  contexts
• Stewardship
• Documents must be managed, shared by the steward
• Potential for authentication
• Intended use as medico-legal documentation
• Wholeness
• Document includes its relevant context
• Human readability
• Essential for human authentication

Slide courtesy of Fred M. Behlen and Harry Solomon
91
Sample CDA
Slide courtesy of Fred M. Behlen and Harry Solomon
92
Narrative and Coded Info

• CDA requires human-readable Narrative Block,
  all that is needed to reproduce the legally
  attested clinical content
• CDA allows optional machine-readable coded
  Entries, which drive automated processes
• Narrative may be flagged as derived from Entries
• Textual rendering of coded entries content, and
  contains no clinical content not derived from the
  entries
• General method for coding clinical statements is
  a hard, unsolved problem
• CDA allows incremental improvement to amount of
  coded data without breaking the model

Slide courtesy of Fred M. Behlen and Harry Solomon
93
Narrative and Coded Entry Example
Slide courtesy of Fred M. Behlen and Harry Solomon
94
CDA Implementation Guides

• Balloted as HL7 Informative Documents
• Describe what amount to templates for CDA
  Documents.
• Specify constraints on CDA content
• Provide Schematron validation of instances
• Each Implementation Guide has a Template ID
  attribute that is included in the root element of
  the conforming document
• Care Record Summary IG released 2005
• Diagnostic Imaging Report IG work in progress
• Also national activities existGerman Medical
  Summary IG (Arztbrief) released by HL7 Germany
  together with VHITG 2006

Slide courtesy of Fred M. Behlen and Harry Solomon
95
CDA and HL7 Messages

• CDA documents are encapsulated as MIME packages
  within HL7 messages
• Can be exchanged in any event/message that
  exchanges documents

96
CDA Conclusions

• CDA is being seen by many as the primary format
  for diagnostic reports and medical summaries
• Allows for a smooth transition from free text to
  coded content
• Can reference external documents such as images,
  signals, films
• Easy to display (simple style sheet)
• Concept of CDA Templates not really well
  thought-out yet
• Implementation guides serve as a replacement
  for now
• Only a content format, no definition of services
  or messages
• many options HL7 v2, HL7 v3, FTP, E-Mail, HTTP,
  SOAP, ebXML etc.
• but no real integration of document and
  communication protocol

97
EHR StandardsDICOM Structured Reporting
98
DICOM Structured Reporting

• Digital Imaging and Communications in Medicine
  (DICOM)
• International standard for medical image
  communication
• Defines file formats for digital medical images
  such as CT, MRI, X-ray, US...
• Specifies various standard network services
  image transmission,archival and retrieval,
  hardcopy on laser films, workflow support etc.
• Virtually all modern digital imaging devices
  support DICOM.
• DICOM Structured Reporting
• An extension of the DICOM standard the exchange
  of structured data
• medical reports, measurements, results, procedure
  logs, etc.