Download EDIS_Functional_Profile_Version_0_6_2006-08-01

Emergency Department Information Systems
Functional Profile
EDIS Functional Profile Working Group
Emergency Care Special Interest Group
Health Level 7
Co-Chairs
Todd C. Rothenhaus, MD FACEP
Donald Kamens, MD FACEP FAAEM
James McClay, MD, MS
Kevin Coonan, MD
Version 0.6 (8/1/2006)
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
EDIS Functional Profile Working Group
EC-SIG Co-chairs
Todd C. Rothenhaus, MD FACEP
Donald R. Kamens, MD FACEP FAAEM
James McClay, MD MS
Kevin Coonan, MD
Boston University School of Medicine
XPress Technologies
University of Nebraska Medical Center
University of Utah School of Medicine
EDIS Functional Profile Working Group
Randy Case
Dennis G. Cochrane MD FACEP
John Epler
JT Finnel
M. Catherine Glenz RN, BSN
John R. Griffith
Mark Jaben
Richard Hartl MD
Laura Heermann Langford, RN, PhD.
Daniel Myung
JA Magnusun
Dan Pollack
Uhri Randhas
Eric Rock
John Santmann MD
Bharat Sutariya
Chris Thompson, MD, FACEP
Siemens
Morristown Memorial Hospital, Morristown, NJ
Picis
Regenstrief Institute
Alert Life Sciences Computing, Inc.
MEDHOST, Inc.
Haywood Regional Medical Center
Wellsoft, Inc
Intermountain Healthcare
Boston University
Oregon Department of Human Services
Centers for Disease Control
MEDHOST, Inc.
MEDHOST, Inc.
Wellsoft, Inc.
Cerner, Inc.
Touch Medix, LLC
2
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
3
Emergency Department Information Systems (EDIS) - Functional Profile
Emergency Care Special Interest Group – HL7 VERSION 0.6 08/1/2006
Welcome to the EDIS Functional Profile (EDIS-FP) project of the HL7 Emergency Care SIG (EC-SIG). The project is
aimed at developing an HL7 Informative Functional Profile for emergency department information systems (EDIS),
conforming to the HL7 EHR Functional Model, under the auspices and direction of the EHR Technical Committee. By
creating a robust and usable functional profile that includes specific and relevant conformance criteria, we hope to
develop an open and objective standard for development, refinement, and comparisons between ED information systems.
In 2003, the EHR TC (then a special interest group) began development of a functional model for electronic health record
systems (EHR-S). Subsequently, a number of organizations approached HL7 to accelerate development of a consensus
standard to define the necessary functions of an EHR. The EHR SIG was promoted to a full technical Committee and in
2004 published the EHR-S Functional model as a Draft Standard for Trail Use (DSTU). The EHR Functional Model
remains in development.
The EHR-TC intends that unique functional profiles will be developed by subject matter experts in various care settings or
domains (i.e. ambulatory, inpatient, anesthesia, long-term care). These functional profiles will serve to inform developers,
purchasers, and other stakeholders of the functional requirements of systems developed for these domains. Recently, the
Certification Commission on Health Information Technology (CCHIT) adopted the EHR FM as a tool for evaluation of
ambulatory and inpatient EHR systems. The EC-SIG has been in communication with the leadership of CCHIT and
intends to advance the EDIS-FP as the standard for evaluation of emergency department information systems.
The EC-SIG was founded last year to inform the HL7 and other standards development organizations (SDOs) of the
unique HIT requirements and workflows of emergency care. The EC-SIG co-chairs solicited input and membership from
domestic an international specialty societies, including but not limited to, ACEP, SAEM, AAEM, ENA, and the Canadian
and Australasian Emergency Medicine Societies. Participation was also thoroughly solicited from the vendor community
through invitations and presentations.
In 2005, American College of Emergency Physicians (ACEP) joined HL7 and sponsored membership in the EC-SIG in the
form of 4 memberships and 2 funded awards for travel and expenses. Sufficient infrastructure was secured from an
unrestricted grant from X-press Technologies to set up an intranet site and weekly teleconferences to supplement thrice
yearly face to face meetings at HL7 workgroup meetings. Members of the EDIS-FP include physicians, nurses, medical
informatics experts, EDIS developers, engineers, and other representatives from the vendor community.
We began the EDIS-FP project by taking a broad look at the functions required of ED systems and without particular
reference to the EHR FM, which faces open ballot in HL7 in 2006. Using this methodology, we have discovered at least a
few functions that the EHR-TC may have not yet considered in the FM. It has also permitted us to tackle the project in a
manner recognizable to most people working in emergency medicine. Ultimately, harmonization between the workgroup
product and the FM will need to occur for the product to become an HL7 Informative Functional Profile. We anticipate
publication of the workgroup document in a format suitable for practicing emergency department providers and managers
to use as a guide to system evaluation and selection. It is also expected that the EDIS-FP will defines conformance for
both EHR systems and for any subsequent profiles subsequently developed from the FP itself.
The project was planned in four phases:
1. Organization – solicitation of participants, determination of scope and care setting of profile, and development of
project plan and overview (completed).
2. Formalization – step by step development of EDIS functions and conformance criteria (largely completed).
3. Harmonization –comparison with, incorporation into, and alignment with the EHR FM (in process).
a. Incorporate defined EDIS functions through alignment with EHR-FM.
b. Accept or reject other functions from FM.
c. Solicit input from EHR TC for possible new functions.
d. Define priority timeframes (i.e. essential now, essential future) for functions.
e. Incorporate and modify conformance criteria.
4. Finalization – attention to detail, wording, language, conformance and preparation for final EHR – TC approval
and external publication.
The development of the EDIS FP uses the HL7 approach. That is to say that everyone’s contribution or concern needs to
be addressed. Your input is welcome.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
4
Reading this Document
The EDIS FP like the EHR FM, is divided into three broad sections: Direct Care, Supportive Functions and Information
Infrastructure. Each section defines a broad category of functions applicable to
Direct Care
Supportive Functions
Information Infrastructure
We began with a scope of ED care that begins with a “heads-up” and moves through patient arrival, triage, nursing and
physician assessment, orders, results, procedures and ongoing assessments, and finally admit/transfer/discharge
planning. However, many of these traditional concepts or tasks are interspersed throughout the document, depending
upon whether aspects constitute patient tracking, administrative functions, clinical workflow, tasks/orders, clinical
documentation, or clinical decision support, etc. For instance, the triage process can be found in both clinical workflow
and clinical documentation. If a particular aspect of the profile do not make sense, look for pointers to other areas included
in the document.
Functional Priorities
The EHR TC and EC-SIG recognize that clinical computing is an evolving field, and that many of the desired functions of
an EHR-S may not be available at this time. Certain functions, for instance access to regional health information, may not
be feasible or essential now because widespread adoption of RHIOs has yet to occur. Nevertheless, it is important for
functional profiles to outline major trends and articulate a vision for functionality (especially interoperability) for the future.
Furthermore, the delineation of potential functions for future implementation and adoption should guide vendors in
development, and help purchasers develop and articulate to vendors a strategic vision for future functional requirements.
Each function in the EDIS FP is assigned a single priority as follows:
Essential Now
Essential Future
Optional
The function is readily available and the users can implement it. In assigning this priority, the
committee believes that the function is critical to helping an EDIS:
• Support Delivery of Effective Healthcare
• Improve Patient Safety
• Facilitate management of chronic conditions
• Improve efficiency
• Facilitate self-health management
The function should be feasible to implement and readily available to users within the prescribed
period of time.
The function is important or desirable but not a critical component of an EDIS.
Conformance Criteria
Conformance criteria have been developed in accordance with the standards set forth by the EHR technical committee. In
order to ensure consistent, unambiguous understanding and application of the functional profile, the use of a consistent
set of keywords (normative verbs) have been employed to describe conformance requirements.



SHALL – indicates a mandatory, required action. Synonymous with ‘is required’.
SHOULD – indicates an optional, recommended action that is particularly suitable, without mentioning or
excluding other actions. Synonymous with ‘is permitted and recommended’.
MAY – indicates an optional, permissible action. Synonymous with ‘is permitted’
In addition, clarification is necessary to understand the standardized nomenclature used to describe the functions of a
system. The following chart, adapted from the EHR FM, illustrates the hierarchy of nomenclature. For example, “capture”
is used to describe a function that includes both direct entry “create” and indirect entry through another device “input”.
Similarly, “maintain” is used to describe a function that entails reading, updating, or removal of data.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
5
MANAGE
Capture
Input Device (Ext.)
Maintain
Create (Int.)
Read
(Present)
View
Report
Display
Access
Update
Edit
Correct
Amend
Augment
Remove Access
Obsolete
Inactivate
Destroy
Nullify
Purge
ID
T
y
p
e
Name
Statement
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
Direct Care
EDC.1
EDC.1.1
(See: DC.3, S.1.4.2)
H
H
Care Management
Patient Location
Tracking
EDC.1.1.1
F
Track inbound
patients
Track patient physical location through all phases of visit, from pre-arrival through disposition.
In emergency medicine, the concept of tracking within and EDIS connotes multiple concepts. This section refers to tracking
physical location only. Tracking the status of care is covered in Clinical Workflow Tracking and Task Management
Track inbound
The system shall provide a means to track
Most often begins with
patients
a telephone call made
patients who have been referred to the ED.
from referring actor to
The system shall capture and display the
Log information
receiving ED. Often,
Source of Referral.
about incoming
the information gets
referrals from:
haphazardly recorded.
The system shall provide a means to document
physicians offices,
Data must be easily
clinical data on patients who have been referred
clinics, EMS,
accessible, central,
transfers from other
retrievable, updatable,
to the ED.
hospitals or EDs,
AND transportable.
The system shall note the patient who has been
nursing homes,
Clinical data from
referred to the ED as a referral throughout the
others.
provider to provider is
essential to quality
ED stay.
coordinated care for
The system should provide a means to track
patients referred to the
ED. Knowledge of
patients who are en route to the ED via the EMS
patients who are
system.
expected to arrive
helps both ED and
hospital administrative
staff plan resource use
in real time.
For EMS transports,
advanced notification
is common, but not the
rule. This data is most
often taken during a
radio call. Hence,
patient demographic
data is frequently
omitted for privacy
concerns. The system
must allow users to
Identify incoming
ambulances and be
able to reserve bed
and assign human
resources to incoming
patients.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
EDC.1.1.2
F
Track ED patients
Manually (i.e.
actively) or
automatically (i.e.
passively) track
patient physical
location throughout
ED visit.
EDC.1.2
H
Clinical Workflow
EDC.1.2.1
H
Arrival Tasks
EDC.1.2.1.1
H
Patient Registration
EDC.1.2.1.1.1
F
Enter patient into EDIS
7
Description
Rationale/Citations
Comments
EMS arrivals
frequently require inroom registration.
Notification to
registration of
incoming ambulance
can target registration
staff to be available at
time of patient arrival.
Identify the current
location of patient and
the history of
movement throughout
ED visit.
Benchmarks of ED
stay (i.e. triage,
registration, in-room,
disposition, departure)
should be
automatically captured
based on business
logic behind location
and room types.
Proposed Conformance Criteria
Proposed
Comments or
Changes
The system shall provide a means to identify
the current physical location of a patient in the
ED.
The system shall provide a means to update the
current location of a patient.
The system shall record and archive the
movement of patients through the ED.
The system should provide a means to display
the prior location of a patient while still in the ED.
Consider adding
the term “tracking”
to this function
name for clarity.
The interval from patient arrival to delivery of care ordinarily involves multiple steps. In an EDIS, administrative functions
need to be de-coupled from patient care functions.
ED patients frequently require evaluation and treatment prior to ADT registration. The ability to provide care before formal
registration is essential. In addition, many patients are brought directly to patient care areas.
The system shall provide for means for
The system shall
Enter patient into
Sometimes triage
EDIS
personnel can obtain
registration of patients.
permit clinical
demographic
documentation
The system shall allow registration of patients
information. Other
and order entry
times, the volume of
before, during, and after, provision of care.
prior to formal
incoming patients is
registration.
The system should allow a sequential
too great, and triage
must concentrate on
accumulation of registration data,, so that
clinical information
registration does not interfere with the delivery of
only.
care.
Capture demographics
at bedside for patients
brought directly to
The system should provide a means to obtain
demographic data and document consent for
treatment in the triage area.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.2.1.1.2
Name
Statement
John Doe Registration
Enter patient without
demographic data
into EDIS.
(See DSTU.
”anonymous
registration”)
EDC.1.2.1.1.3
Quick Registration
Identify patient in
EDIS and create a
new visit.
EDC.1.2.1.1.4
Merge Registrations
Merge Registrations
EDC.1.2.1.2
EDC.1.2.1.2.1
F
Triage
Manage triage acuity
rating
Provide a means to
capture and maintain
a triage acuity rating
(level) to the patient.
8
Description
Rationale/Citations
Comments
treatment areas.
Patients may present
who are unable to
provide any
demographic data.
Anonymous
registration (John Doe)
also allows RN to pass
entire work of
obtaining and entering
demographics to
registration staff.
To maximize usability,
identification of
patients with prior
visits should be
possible to aid in triage
by recovering prior
medications, allergies,
problems. Time can be
spent verifying,
updating, and
correcting data, as well
as minimize data entry.
This is called “quick
registration” by a
number of vendors.
Formal registration
may occur in EDIS or
hospital ADT system.
A means must be
provided to register
patient in hospital ADT
system and merge
data with EDIS via an
inbound ADT feed, or
alternatively capture
entire demographic
data into EDIS and
send that data to the
hospital ADT system.
Ref: Five-Level Triage:
A Report from the
ACEP/ENA Five-Level
Triage Task Force.
Proposed Conformance Criteria
Proposed
Comments or
Changes
The system should provide for John Doe
registration
The system should allow for quick registration.
The system shall provide a means for merger of
registrations.
The system shall provide a means to assign a
triage acuity rating to a patient.
The system shall permit the use of standardized
This requires
additional
conformance akin
to a longitudinal
care record.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
EDC.1.2.1.2.2
EDC.1.2.1.2.3.
EDC.1.2.1.3
EDC.1.2.1.3.1
T
y
p
e
F
F
H
F
Name
Capture Initial Vital
signs
Manage/Prioritize/Sort/
Triage List
EMS Arrival Tasks
Manage EMS data
Statement
9
Description
Rationale/Citations
Comments
Journal of Emergency
Nursing, Volume 31:
39-50, 2005.
Capture Initial vital
signs
Identify priorities
within the triage list.
Re-prioritize when
necessary,
communicate these
to other care areas in
the ED.
Triage lists are
dynamic, with
changing priorities,
and the necessity for
continued
communication with
other parts of the ED.
Capture and display
EMS data.
Consider future
interoperability
features with EMS
Information Systems
(i.e. automatically
capture data, telemetry
collected electronically
prior to patient arrival).
Capture EMS Data
Information, Tests
Proposed Conformance Criteria
Proposed
Comments or
Changes
ED triage scales
The system shall permit triage acuity rating to
be customized according to locally derived rules.
The system shall provide a means to record
initial vital signs.
The system may provide a means for automated
capture and recording of vital signs via external
devices.
The system shall provide a mechanism to
display patients who are waiting to be seen.
Question as to
what this means?
The system should provide a means to sort or
display patients who are waiting to be seen by
various criteria.
This may be better
moved to
EDC.1.5.1
Capture ED Arrival
Data
The system should provide a mechanism for
recording and retrieval of pre-hospital
information.
The system shall
provide a
mechanism for the
capture of
electronic EMS
data (i.e. EKG,
telemetry,
defibrillator data).
When available, the system should
electronically capture EMS Data, EMS
Telemetry, and display alarms and concerns.
When electronic capture is not available to EMS,
the system may allow EMS personnel to easily
input EMS data, telemetry, and other information
into the system.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.2.2
H
Name
Clinical Workflow
Task Management:
Creation, Display,
Prioritization, and
Notification
See: EHR-FM:
Clinical workflow
tasking (DC 3.1)
Clinical task
assignment and routing
(DC 3.1.1)
Clinical task linking
(DC 3.1.2)
Clinical task tracking
(DC.3.1.3)
Clinical task timeliness
tracking
(DC.3.1.3.1)
10
Description
Proposed
Rationale/Citations
Proposed Conformance Criteria
Comments or
Comments
Changes
In the ED, there exists a critical need for distributed communication of the status of workflow tasks. An essential EDIS
function is the management and display of tasks to be accomplished. In the pre-EHR era, this was accomplished by
“artifacts” (grease boards, chart racks, etc.). Systems in the ED, therefore must seek to achieve the a level of embedded
buy-in and participation as have home-grown artifacts.
Statement
Communication of priorities is difficult in the ED. Work to be done is constantly changing. For instance, a critically ill patient
has the immediate effect of re-prioritizing all workflow. In the ED, shifting of priorities is the norm, not the exception.
Tasks in the ED are usually assigned to at least one member (or department) of the healthcare team. Tasks are generally
linked to a particular patient, or occasionally to infrastructure in the ED (i.e. bed needs cleaning). The EDIS should be
extensible enough to accommodate the complexity of clinical task routing according to local needs. For instance, in one
ED, the assignment of a task “Chest Radiograph” may be assigned to the patient’s primary RN alone (sub-optimal), who
carries out the task of ordering the study in the RIS and contacting transport to take the patient to the radiology
department. In another ED, the same task might entail the creation of multiple sub-tasks to:

Alert the primary RN that the patient requires transport out of the department

Alert the radiology technologist to perform the study

Alert the transporter to transport the patient to radiology

Send an HL7 message to the RIS ordering the study.
The tracking and display of tasks takes two major forms:

The status and display of tasks for a particular member of the healthcare team (i.e. MD, RN or Tech) or an external
department (i.e. Radiology, Laboratory, Admitting)

The status and display of tasks for an individual patient
In an EDIS, the optimal display of clinical tasks is visible, and communicates at a distance.
EDC.1.2.2.1
F
Task Management
Manage ED tasks
with the EDIS
See: Clinical workflow
tasking (DC 3.1)
EDC.1.2.2.2
F
Task assignment and
routing
See: Clinical task
assignment and routing
(DC 3.1.1)
Assign tasks to ED
providers or ancillary
departments.
Provide a means to
identify tasks in the
EDIS.
Examples include:

Tests/X-Ray/Lab

Clinical Tasks

Consultations

ADT (placed in
disposition
section)
The system shall maintain a list of tasks.
The system shall permit the creation of new
tasks.
The system shall permit prioritization of tasks
according to patient severity, LOS, or other
criteria.
The system shall permit the delegation of tasks
to one or multiple providers.
The system shall permit the provider to reprioritize tasks.
The system shall notify the clinicians when tests
and laboratory results have been returned for
review.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.2.2.3
EDC.1.2.2.4
11
Description
Rationale/Citations
Comments
Name
Statement
F
See: Clinical task
linking
(DC 3.1.2)
F
Display/Notify Status of
Care
Link clinical tasks to
a particular patient,
an object, or a place
in the ED chart.
Display those tasks
which have been
ordered or initiated,
but have not been
completed.
The system shall link each clinical task to a
patient, an object in the department (i.e. bed to
be cleaned), or a place on the patient’s ED chart
(i.e. interpretation of ECG).
The system shall track creation,
acknowledgment, and completion of tasks.
Display and notify
providers about tasks
which have returned
results that are
awaiting review.
The system shall display an up to date list of
tasks to be done by patient.
See: Clinical task
tracking (DC.3.1.3)
Proposed Conformance Criteria
The system shall display an up to date list of
tasks to be done by provider.
This system shall display tests and radiological
studies that have been ordered.
The system shall notify the clinician when
clinical tasks are complete.
The system shall display consultations which
are pending.
The system should notify of the completion of
consultations.
EDC.1.2.2.5
F
Display overdue tasks
or results.
See: Clinical task
timeliness tracking
(DC.3.1.3.1)
Display and notify
providers of tasks
which are overdue.
The system may display ETA of consultations.
The system shall display tasks which are
overdue.
The system shall flag tasks that have not been
completed at the time of disposition.
The system should flag results that have been
received but have not been reviewed.
The system should flag tasks that are not
complete but not expected to be complete as
requiring follow up.
Proposed
Comments or
Changes
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
EDC.1.3
H
Orders
Provide means to
order laboratory,
radiology,
medications, nursing
tasks, and materials
management through
the EHR application.
EDC.1.3.1
F
Manage Orders
Maintain a master list
of orders.
12
Description
Rationale/Citations
Proposed Conformance Criteria
Comments
Orders are a unique subset of clinical tasks that possess certain qualities.
An individual order may actually comprise a number of bundled tasks. For instance, an order for a
complete blood count may comprise a number of sub-tasks, including:

Draw the blood specimen

Transport the specimen to the lab

Initiate the order in the laboratory system

Create a task to review and document results
It should be recognized that for success, orders must be highly specific and customizable by
personnel role, physical location, and other patient specific factors (i.e. major trauma patient). The
system must be sufficiently extensible to support institutional variations and preferences.
For instance, the order for an ECG may be carried out by an ED RN in one institution, and a
person from heart station in another. Aerosol therapy may be the purview of nursing in one ED
and respiratory care in another.
The system shall provide a means to maintain a
Each institution is
different. The EDIS
list of orders.
serves as an interface
The system should provide a means for the
to that institution.
Hence a customized
creation of both role-based and location-based
list of potential orders
orders.
is required.
The system should provide a means to define a
workflow of related tasks.
The system should provide a means to create
groupings of tasks.
The system should provide a means to name
orders according to a local taxonomy.
The system shall provide a means to flag and
allow the treating physician to co-sign or
countersign non-physician orders.
The system may provide a means for subclassification of order types based upon local
interoperability needs.
EDC.1.3.2
F
Manage Order Sets
See: DC.1.4.3
Provide order sets
based on provider
input or system
prompt.
Proposed
Comments or
Changes
Order sets, which may
include medication
orders, allow a care
provider to choose
common orders for a
particular circumstance
or disease state
The system shall provide a means for the
creation of order sets.
The system should permit the inclusion of all
order types relevant to a particular problem (i.e.
laboratory, radiology, medications, nursing
tasks, and materials management).
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
13
Description
Rationale/Citations
Comments
according to best
practice or other
criteria.
Recommended order
sets may be presented
based on patient data
or other contexts.
EDC.1.3.3
F
Manage diagnostic
orders
See:
Order diagnostic tests
(DC.1.4.2)
Submit diagnostic
test orders
Provide a means for
providers to order
diagnostic tests
including, but not
limited to, laboratory,
radiology, and special
procedures.
Proposed Conformance Criteria
Proposed
Comments or
Changes
The system should allow for the update of order
sets.
The system should allow for the customization
of order sets by provider type.
The system should allow for the customization
and/or presentation of order sets by patient age,
sex, or other patient factors.
The system may allow for the customization of
order sets by physician.
The system shall maintain a list of laboratory
and radiological studies available to the clinician.
The system shall provide a means for clinicians
to order laboratory tests.
The system shall provide a means for clinicians
to order radiological studies.
The system shall prompt the clinician to provide
the necessary information to transmit a complete
order for any orderable item.
The system should, for each orderable item,
automatically provide as much data as possible
to transmit the order.
EDC.1.3.4
F
Manage therapeutic
orders
See: Medication
ordering and
management
(DC.1.3), RN
documentation and
Prescription writing in
EDC.1.5.1
The system should provide a flag of certain
diagnostic studies that are being repeated within
a proscribed period of time.
The system shall provide a means to create ED
medication orders with detail adequate for
correct filling and administration.
The system should support institution specific
formularies.
The system shall provide drug-drug, and drug
allergy interaction checking.
The system shall
provide a list of
medications to
search from,
including both
generic and
brand name.
The system shall
interface with
systems of blood
banks or other
sources to
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
14
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
manage orders
for blood
products or other
biologics.
The system shall
provide a means
to institute cosignatures for
therapeutic orders
based upon roles
(i.e. medical
student, consulting
physician).
EDC.1.3.5
F
Manage patient care
orders
Provide a means to
order care provided
wound care, diet,
monitoring and other
care.
The system shall provide a means to order
intravenous catheter placement and fluid
therapy.
The system shall provide a means to order
dressings and wound care
The system shall provide a means to order a
diet for the patient, including NPO status.
The system shall provide a means to order
cardiopulmonary monitoring.
The system shall provide a means to order an
ECG.
EDC.1.3.6
F
Manage patient
education orders
Provide a means to
order patient
education.
The system shall provide a means to order
ventilator therapy.
The system shall provide a means to order
specific patient education tasks.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.4
H
EDC1.4.1
F
Name
Manage Diagnostic
Test Results
Display Diagnostic
Results
Statement
Provide means to
view results of
diagnostic studies.
15
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
The system shall provide means to view results
of diagnostic studies ordered during the ED visit.
The system should provide a means to view
laboratory results in trend view.
The system should provide a means to view
results of diagnostic studies ordered during prior
ED visits.
F
Notify Clinician of
Abnormal
Results/Panic values
and results.
The system may provide a means to view prior
diagnostic studies ordered within the same
institution.
The system may provide a means for notifying
clinicians of abnormal results.
The Laboratory
usually handles
this. However. We
need to recognize
that this may be
an EDIS function.
Other ways of
notification of
significantly
abnormal results
may be developed
in the future.
The system
should provide a
mechanism for
review of
diagnostic test
results ordered
that have not
returned before
completion of the
ED visit.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.5
H
EDC.1.5.1
F
Name
Clinical
Documentation
Merge Pre-Arrival Data
16
Statement
Description
Rationale/Citations
Comments
Merge inbound
(EMS, telephone,
transfer) data with
record being created
for visit.
Merge data collected
prior to patient arrival
with record created to
provide means to
access data in record.
Proposed Conformance Criteria
The system shall provide a means to display
pre-arrival data during triage.
The system shall provide a means to merge
data collected prior to patient arrival with the
record begun at the time of arrival.
Proposed
Comments or
Changes
The system shall
provide a
mechanism to
merge inbound
data with the
patient’s record.
See: EDC.1.1.1
The system may provide a means to import the
EMS run sheet.
(Consider moving
to interoperability
section)
EDC.1.5.1
F
F
ED Arrival Data
Focused Triage
Assessment
F
Comprehensive Triage
Assessment.
F
Patient Medical History
Capture ED Arrival
Data
Capture Focused
Triage Assessment
Capture data pertinent
to ED visit including,
but not limited to:
Mode of arrival
Referral source
Arrival time
(See: DEEDS 1.0 and
National Emergency
Encounter Registry)
Also called “quick
triage” for patients who
arrive when triage is
delayed, or for patients
who may undergo a
multi-step triage
process.
For patients who arrive
and are non critical or
will undergo a single
triage assessment.
The system shall provide a means to capture
ED arrival data.
The system shall capture and display time of
arrival.
The system should provide a mechanism to
vary the information taken at triage, depending
on local practice.
The system should provide a mechanism to
vary the information taken at triage, depending
on patient circumstances.
The system shall provide a means to document
a focused triage assessment.
The system shall provide a means to capture
chief complaint.
The system shall provide a means to document
a comprehensive triage assessment.
The system shall provide a means to document
past medical history, medications, and allergies.
The system should provide a means to manage
allergies and medications as coded data.
The system should provide a means to capture
family history and social history.
The system shall
provide a means
to record past
immunizations.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.5.2
EDC.1.5.3
Name
Statement
F
Manage Nursing
Documentation
F
Medication
Administration Record
(MAR)
Provide means for
nurses to document
care provided to
patients.
Medication
Administration
Record (MAR)
17
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
The system shall provide a means for nurses to
document assessments and care delivered to a
patient
The system shall provide a means to document
medications and other therapeutic agents
administered in the ED.
The system shall
present a list of
medications to be
administered.
The system shall
unambiguously
display the timing
route and dose of
all medications on
the list.
The system may
provide a means
for barcode
recognition
verification of
patients.
Others from
DC.1.8.2
EDC.1.5.3
H
Manage Physician
Documentation
Provide a means to
capture and maintain
physician
documentation.
ED patient commonly
receive care, and care
must be documented,
before registration is
completed.
The system shall provide a means of clinical
documentation for all ED providers.
Care and
documentation
frequently occur in a
non-linear temporal
sequence. However,
clinical summaries
created by the EDIS
should re-create a
traditional or standard
type of record flow.
The system shall reconcile documentation
made in a non-linear temporal sequence.
The system shall permit clinical documentation
before the patient is registered.
The system shall provide a means to distinguish
between time of observation and time of data
entry.
The system should provide multiple levels of
data display (log view versus readable view) vs.
not display at all.
Needs to be
moved or deleted.
Needs to be
moved.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
EDC.1.5.3.1
F
Manage patient history
Provide a means to
capture and maintain
HPI, PMH, Meds,
Allergies and ROS.
18
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
The system shall provide a mechanism for
incorporation of the patient’s history.
The system should provide a means for the
system to incorporate the HPI as narrative
and/or story.
The system may provide a means to incorporate
the HPI as data elements.
EDC.1.5.3.2
F
Manage physical
examination
EDC.1.5.3.3
F
Manage lab, radiology,
other diagnostic tests
interpretation
Provide a means to
capture and maintain
physical
examination.
Provide a means to
capture and maintain
lab, radiology, other
diagnostic tests
interpretation.
Proposed
Comments or
Changes
This may be quite
controversial.
Discussion
regarding
narrative vs.
template based
styles.
Should
conformance
weight narrative
and template
styles equally?
Should narrative
style be a backup
for complicated or
subtle
presentations?
Do we need
granularity
conformance as
above?
The system shall provide a means to record
ECG interpretations by the emergency
physician.
The system shall provide a means to record
laboratory test interpretations by the emergency
physician.
The system shall provide a means to record
plain radiograph interpretations by the
emergency physician.
The system shall provide a means to record
initial (“wet”) and final radiograph interpretations
by the radiology department.
The system should provide a means to
document and reconcile discrepancies between
initial and final radiographic interpretations.
The system should integrate with RIS or PACS
system for ED, wet reads and final radiologist
interpretations.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
EDC.1.5.3.4
T
y
p
e
F
Name
Manage consultation
requests and
responses
Statement
Provide a means to
capture and maintain
requests for
consultation and
responses.
19
Description
Rationale/Citations
Comments
The EHR should have
easily referenced
means to document
and note calls made to
consultants, as well as
their responses.
Proposed Conformance Criteria
The system may integrate with RIS or PACS
system for viewing images obtained during ED
visit.
The system shall provide a means to record
consultations by providers other than the
emergency physician.
Proposed
Comments or
Changes
See DC.1.9.5
It is even
conceivable to
initiate calls from a
dropdown, and
verify returns in a
similar manner.
Must document
time paged,
responded, arrived
and final
recommendation.
EDC.1.5.3.5
F
Manage medical
decision making
F
Manage progress notes
F
Manage transfers of
care
EDC.1.5.3.8
F
Document procedures
EDC.1.5.3.9
F
Document patient and
family education
EDC.1.5.3.6
Including development
of differential diagnosis
and process used to
exclude lifethreatening diagnoses.
The system shall provide a means for
physicians to document medical decision
making including development of differential
diagnosis and process used to exclude lifethreatening diagnoses.
Should include
medico-legal and
billing aspects.
The system should provide a mechanism to
incorporate narrative interpretation of the
physician’s decision making process
Provide a means to
capture and maintain
progress notes or
ongoing evaluations.
Provide a means to
capture and maintain
transfers of care
between ED
providers
Provide Mechanism
for Documentation of
Procedures
Include Documentation
of Events,
Deteriorations, Arrests
The system shall provide a means to record
progress notes by providers.
Provide a
mechanism for
documentation of
patient and family
A Function allowing for
entry/retrieval of a
description of the
counseling given to the
Provide a means to
capture and maintain
medical decision
making
The system shall provide a means to record
procedures performed on the patient.
The system shall provide a means to document
patient education, counseling, and
communication with the patient’s family by the
emergency physician.
The system
should provide a
means to record
sufficient data for
billing.
The EHR should
show not only the
thinking about a
patient's condition,
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
communications,
counseling, and
education.
EDC.1.5.5.2.2
F
Manage Advanced
Directives
EDC.1.5.5.2.3
F
Flag Patient with
Special Needs
20
Description
Rationale/Citations
Comments
Patient/Family
regarding the condition
(for which the patient
was seen in the ED)
Provide mechanism to
retrieve and flag
advanced directives.
Provide a means to
note special needs of
patient as they may
pertain to the ED
visit.
People with special needs
include:
wheel chairs, people who
are blind or visually
impaired, people who are
deaf or severely hard of
hearing, people with
severe emotional
impairments, people with
severe intellectual
impairments, people with
medically related needs
such as diabetics,
individuals with seizure
Proposed Conformance Criteria
The system shall provide a means to document
patient education provided to the patient or
family.
Note: “Management of Advance Directives
dropped from EDIS FM in deference to EHR-FM
DC.1.11 (Preferences, Directives, Consents,
Authorizations). There are however, some CC
for DC.1.11.3 (Manage Consents and
Authorizations) that might be elevated to “shall”
in the EDIS profile.
Proposed
Comments or
Changes
but also what was
communicated to
patient/family, so
that subsequent
physicians to
whom the patient
is referred have a
grasp of
conversations that
have already
taken place.
Submitted by Neal
Handly: See
DSTU DC.3.2.1||
Inter-provider
Communication
and DC.3.2.3 ||
Provider and
patient or family
communication
and DC.3.2.4
Patient, family and
care giver
education.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
21
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
disorders, and many
others that require unique
assistance. Individuals
with disabilities are
defined as persons who
have physical or mental
impairment that limit
major life activities, have
an ongoing or chronic
condition, or even if they
don’t have such a
condition, are regarded by
the community as being
disabled. And this doesn’t
necessarily include the
ever-enlarging group of
senior citizens who have
a greater number of
special needs including
Alzheimer’s and related
memory disorders"
EDC.1.5.5.3
H
Verify InterPractitioner
correctness
Acknowledge/Amend
Other Provider
Documentation
(may be best function
name for this header).
An important aspect of ED documentation is the cross-check during clinical time for pieces of
information that are sometimes gleaned from one practitioner (say a nurse), and must be reflected
in the documentation of other key care givers (say physician). Sometimes this means
commenting on findings that are not duplicated, sometimes it means verification of findings, but in
all cases it means not having discrepancies which can be of severe medical and medical-legal
consequence.
The system shall provide a means to mark the
Assistants (Physician,
Rank of
Nursing)
documentation as read by another provider.
observations (i.e.
Attending vs.
The system shall provide a means to mark
Ancillary Care
resident vs. RN
(Technicians, etc)
documentation by another provider as agreed
vs. student.)
Other care givers (RT,
with.
PT, etc).
Agree to disagree
vs. reconciliation
Can this be made
a conformance?
The system
should permit the
physician to agree
or disagree with
other provider
documentation.
Amended, vs.
wiped out vs.
corrected.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
EDC.1.5.5.3.1
F
Review nurses notes
Scan/review nurses
notes, annotate for
disparities, import
when desired.
EDC.1.5.5.3.2
F
Review other care giver
notes
EDC.1.5.6
F
Attending Attestation
Scan/review notes,
annotate for
disparities, import
when desired.
Enable focused
annotation of a
supervisee’s note by
the attending ED
physician.
EDC.1.5.7
F
Allow Other Provider
Documentation
22
Description
Rationale/Citations
Comments
This is a key function
of any coherent ED
EHR system. Making
this happen easily and
smoothly will be a
matter of
implementation. But
making it at least
happen, in my mind,
should be a minimum
function.
Summarize any
annotations at the
digital signature level
for attestation of
supervision note.
EHR which masters
this function will be
welcome. Again,
smooth
implementation is one
issue. But a minimum
requirement (or option)
for teaching
institutions...makes
sense.
Enable capture of
documentation created
by providers other than
primary caregivers in
the ED.
Consultants generally
do not use the EDIS to
document care.
A method should be
available to capture or
link these documents
to the ED visit.
Proposed Conformance Criteria
The system shall provide a means for the
attending ED physician to attest to supervising
care. CMS 100.1.1
Proposed
Comments or
Changes
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
EDC.1.5.8
H
Name
Manage Record
Completion
23
Description
Proposed
Rationale/Citations
Proposed Conformance Criteria
Comments or
Comments
Changes
Delineate the timing, means, and circumstances by which ED records are created and completed. While ED records are
ideally completed by the time a patient leaves the department, this is not always possible. Moreover, ED records are often
created discontinuously, and systems need to consider provisions for permitting staggered, delayed, and offsite completion
of records as well as monitoring and reporting their completion. Furthermore, EDIS systems should consider the process of
authorship (one or more providers), signature, authentication, completion and addendum of ED records.
Statement
Provide means to scan and view patient records needing attention or completion.
Needing additions after signature. Legally restricted.
Completions of chart in sequence…say one doctor, then another.
Completion of a chart by multiple care givers at one time.
After provider leaves premises, but before signature (reported incidence with some EHRs by underground reports. may be
a habit holdover from dictation).
Simultaneous holding of multiple, partially completed charts, on different patients.
ED Physicians sometime do not get documentation completed at the end of each shift. Although some stay afterward to
complete the work, others take the work home, and complete the medical record over the next 24-36 hours. It is
conceivable in a busy shift that a physician may want to look over his/her clinical documentation before signage. Although
this is not ideal, facilities should have the option to add this feature, when the workflow demands it?
Completion of parts of chart on any one patient, out of sequence, later synthesized… Because of the commonly irregular,
sometimes chaotic, and piecemeal acquisition of information in the ED, documentation is often accomplished in fragments,
and sometimes outside of the sequencing used in other care spaces. Documentation should be able to be done in any
order, with good perspectives of what has and has not been completed, as well as what remains to be completed.
After patient care… ED clinicians sometimes must wait until the end or stay after an assigned shift, to find time to complete
records.
EDC.1.5.8.2.1
F
Record Completion
The system shall allow for discontinuous
completion of ED records.
The system should keep clinicians informed of
the state of completion of each record.
The system should enable the clinician to
choose which section of the record to edit.
The system shall provide a means to move
between incomplete patient records without loss
of work.
The system shall permit the delayed completion
of records.
The system should display a list of records that
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
24
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
Proposed
Comments or
Changes
remain to be completed.
The system may allow for completion of records
offsite.
The system shall allow each facility to
determine use, or non-use of this function,
according to medical staff, hospital, or other
rules.
The system should enable the facility to
determine who is authorized to use offsite
completion.
The system should allow the facility to
determine the time limits under which
completion must be accomplished.
EDC.1.6
H
EDC.1.5.3.7
F
Disposition
Management
Manage disposition
EDC.1.6.1
H
Manage discharge
EDC.1.6.1.1
F
Manage prescriptions
Provide Mechanism
for Documentation of
Disposition,
Disposition Status,
Follow up
Provide means to
create a complete
and tailored
discharge package
for patients
discharged from the
ED. Includes
instructions,
prescriptions, and
follow up information.
Provide a means to
create prescriptions
for patients
discharged from the
ED.
The system shall provide careful monitoring and
reporting related to use of this function,
according to operative rules.
The system should display patients ready for
disposition.
The system shall provide a means to record the
final disposition of the patient from the
emergency department.
Final dispositions
should be coded
in DEEDS.
The system shall create a record of the
materials provided to the patient at discharge.
The system shall provide a means to create
outpatient prescriptions with detail adequate for
correct filling and administration.
The system may provide a means to create and
securely transmit electronic prescriptions in
compliance with current regulations.
The system
should provide a
means to calculate
doses based on
weight.
The system may
provide a means
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
EDC.1.6.1.2
T
y
p
e
F
Name
Statement
25
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
The system should provide the ability to tailor
formularies by institution, insurance or other
local rules.
The system shall provide a means to manage
discharge instructions.
Manage discharge
instructions
The system may provide the ability for individual
providers to manage their discharge instructions.
The system shall provide a means to edit
discharge instructions for a particular patient.
The system should provide a means to create
patient discharge instructions in multiple
languages.
The system may provide a list of appropriate
discharge instructions based on age.
The system may provide a list of appropriate
discharge instructions based on sex.
The system may provide a list of appropriate
discharge instructions based on diagnosis.
The system may provide a list of appropriate
discharge instructions based on reading level.
The system shall provide a means to document
that instructions were given.
The system may provide a means to capture via
digitized signature that instructions were given.
EDC.1.6.1.3
EDC.1.6.1.4
F
F
Manage follow-up care
Manage custom forms
Scheduled vs.
unscheduled follow up.
Provide means to
produce school or
work notes and
document
occupational
recommendations.
The system shall provide a means to provide
scheduled or intended follow up for patients
discharged from the ED.
The system shall provide the ability to manage
a list of follow up physicians, offices, or clinics.
The system shall provide a means to manage
work, school, or other custom forms.
Proposed
Comments or
Changes
to calculate doses
based on renal
function.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
EDC.1.6.2
H
Manage Admission
Statement
26
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
The system should clearly display the time
between disposition initiation and disposition
achieved.
Proposed
Comments or
Changes
The system
should notify when
disposition is
complete.
The system should provide a means to notify
admitting that a bed request.
The system should provide a means to specify
sufficient detail to request a particular bed.
The system should capture when a bed
becomes available
The system should capture when a patient is
ready for transport to inpatient bed.
H
Manage Transfers
The system should capture when the patient
leaves the ED.
The system shall provide a means to create
legal transfer documentation.
The system shall capture the name of the
accepting physician.
EDC.1.6
H
Post-Disposition
Management
The system shall capture the name of the
accepting facility.
The system needs to provide a means to track all flavors of outstanding patient issues after the ED visit is completed. For
example, the system should allow providers to identify patients with outstanding laboratory, radiological, or other diagnostic
study issues, or to arrange follow-up care that could not be adjudicated prior to discharge. These tasks may be delegated
to a particular person or may be displayed to entire ED staff. In addition, the system needs to track patients requiring
administrative action after discharge (i.e. patient satisfaction or other non-clinical follow-up).
Furthermore, the system need to provide a means to reconcile preliminary diagnostic test results with the final
interpretations of the services requested (i.e. reconcile ED interpretation with ultimate radiologist dictation).
Hence, interoperability with radiology information system and ECG system (not traditional interfaces) becomes desirable
(see interoperability).
EDC.1.6.1
F
Manage discharged
patients
Note: the EHR FM seems to have a series of related functions but no specific function for this critical activity of
assuring that the care sequence has been followed.
The system shall provide a mechanism for the
Provide a means to
The system
should provide a
capture and maintain
management of radiological follow-up for
outstanding patient
discharged patients.
means to flag
issues after the ED
discrepancies
The system shall provide a mechanism for the
visit is completed.
between ED
management of administrative follow up for
physician
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
ID
T
y
p
e
Name
Statement
27
Description
Rationale/Citations
Comments
Proposed Conformance Criteria
discharged patients.
The system shall provide a mechanism for the
management of clinical follow-up for discharged
patients.
Proposed
Comments or
Changes
interpretation,
radiology wet
reads, and final
interpretations of
radiographic
studies.
The system
should provide a
means to flag
discrepancies
between ED
physician
interpretation
cardiologist
interpretations of
ECGs.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
28
EDC.2
H
Clinical Decision
Support
The concept of decision support encompasses a large number of potential applications and functions.
EDC.2.1
F
Evidence Based Triage
Provide a means for
triage staff to assign
triage categories.
From EDC.3.1
F
Waiting Room
Management
Provide a means to
view and prioritize
patients based upon
acuity, waiting time,
and practitioner load.
Offer prompts to
support the
adherence to care
plans, guidelines,
and protocols at the
point of information
capture.
Support for standard
assessments
Support for Patient
Context-enabled
Assessments
Offer prompts based
on patient-specific
data at the point of
information capture.
This is the CDS
analog to the
triage lists.
When a clinician fills
out an assessment,
data entered triggers
the system to prompt
the assessor to
consider issues that
would help assure a
complete/accurate
assessment. A simple
demographic value or
presenting problem (or
combination) could
provide a template for
data gathering that
represents best
practice in this
situation, e.g. Type
II diabetic review, fall
and 70+, rectal
bleeding etcetera. As
another example, to
appropriately manage
the use of restraints,
an online alert is
presented defining
the requirements for a
behavioral health
restraint when it is
selected.
When a clinician fills
out an assessment,
data entered is
matched against data
already in the system
1. The system SHALL access the standard
assessment in the patient record and related to
the patient specific problem list.
2. The system SHALL enable access
to standards and practices related to age,
gender, normal growth and development and
medical conditions.
3. The system SHOULD enable comparisons
between elements of assessments captured by
the clinician and those prevalent in the best
available practices relevant to age, gender,
development and medical conditions
4. The system MAY derive supplemental
assessment data from evidence based standard
assessments, practice standards, or other
generally accepted, verifiable, and regularly
updated standard clinical sources.
5. The system SHOULD provide prompts based
on practice standards to recommend additional
assessment functions.
6. The system SHOULD enable updating of the
problem list by activating new problems and
deactivating old problems (DC 1.5) as
identified by conduct of standard
assessments.
The system SHALL access the standard
assessment in the patient record and related to
the patient specific problem list. (DC 1.4)
The system SHALL enable data
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
29
to identify potential
linkages. For example,
the system could scan
the medication list and
the knowledge base to
see if any of the
symptoms are side
effects of medication
already prescribed.
Important but rare
diagnoses could be
brought to the doctor’s
attention, for instance
ectopic pregnancy in a
woman of child bearing
age who has
abdominal
pain.
Support for
identification
of potential problems
and
trends
Identify trends that
may lead to
significant problems,
and provide prompts
for consideration.
When personal health
information is collected
directly during a
patient visit input by
the patient, or acquired
from an external ource
(lab results), it is
important to be able to
identify potential
problems and trends
that may be patient
specific, given the
individual's personal
health profile, or
changes warranting
further assessment.
For example:
significant trends (lab
results, weight); a
decrease in creatinine
clearance for a patient
on metformin, or an
capture to a very small scale for
unique situations, such as premature
infants as well as patient context
assessment features relevant to
presenting medical conditions
3. The system SHALL enable access
to standards and practices for age,
gender, developmental stage, and
medical condition presenting at the
time of the encounter.
4. The system SHALL enable
comparisons between additional
assessment data entered during the
encounter and the accessed standards and
practices.
5. The system SHOULD enable
messages to prompt providers to
conduct additional assessments or
testing based on differences
between the current assessment
and the accessed practice standards
6. The system SHOULD enable
comparisons of medical data and
patient context assessments to the
accessed practice standards to
prompt additional testing, possible
diagnoses, or adjunctive treatment.
1. The system SHALL access the
standard assessment in the patient
record. (DC.1.4)
2. The system SHALL relate the
standard assessment to the patient
specific problem list. (DC 1.5)
3. The system SHOULD enable access
to standards for age, gender,
developmental stage, and medical
condition presenting at the time of
the encounter.
4. The system SHOULD compare
patient context assessments and
additional medical information to
best available practices to identify
patient specific growth and
development patterns, health trends
and potential health problems
5. The system SHOULD enable
configuration rules for abnormal
trends
6. The system SHOULD prompt with
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
30
abnormal increase in
INR for a patient on
warfarin.
abnormal trends
7. The system SHOULD prompt for
additional assessments, testing or
adjunctive treatment
8. The system SHOULD enable entry
of decisions regarding prompts or
override of prompts.
9. The system MAY integrate with
appropriate teaching materials
1. The system SHALL provide access
to standard care plans, protocols and guidelines
when requested within the context of a clinical
encounter. These documents may reside within
the system or be provided through links to
external sources.
2. The system MAY support the creation and
use of site-specific care plans, protocols, and
guidelines.
3. The system MAY support site-specific
modifications to standard care plans, protocols,
and guidelines obtained from outside sources.
1. The system SHALL support access to
resources for care plans that are context
sensitive to patient specific data and
assessment, and are appropriate to the age,
gender, developmental stage and medical
condition of the patient (DC 1.3.1, DC 1.4, DC
1.5, DC 1.6)
2. The system SHOULD suggest context
specific care plan(s) appropriate to the
presenting problem(s) of the patient
3. The system MAY capture care process across
the continuum of care
4. The system MAY display care processes
across the continuum of care
5. The system MAY enable and document the
choice of action in response to care plan
suggestions.
Support for standard
care
plans, guidelines,
protocols
Support the use of
appropriate standard
care
plans, guidelines
and/or
protocols for the
management of
specific conditions.
At the time of the
clinical encounter,
standard care
protocols are
presented. These
may include sitespecific
considerations.
Support for context
sensitive care plans,
guidelines, protocols
Identify and present
the appropriate care
plans, guidelines
and/or protocols
for the management
of specific conditions
that are patientspecific.
At the time of the
clinical
encounter (problem
identification),
recommendations for
tests,
treatments,
medications,
immunizations,
referrals and
evaluations are
presented based
on evaluation of
patient specific
data, their health
profile and any
site-specific
considerations. These
may be modified on
the basis of
new clinical data at
subsequent
encounters.
Support consistent
management of patient
groups or populations
Support for research
Probably not
Provide support for
The clinician is
1. The system SHALL support
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
31
protocols relative to
individual patient care.
the management of
patients enrolled in
research
protocols
presented with
appropriate protocols
for patients
participating in
research studies,
and is supported in the
management and
tracking of
study participants.
Support for drug
interaction checking
Identify drug
interaction
warnings at the point
of medication
ordering
The clinician is alerted
to drugdrug,
drug-allergy, and drugfood
interactions at levels
appropriate
to the health care
entity. These
alerts may be
customized to suit
the user or group.
presentation of appropriate protocols
for patients enrolled in research
studies
2. The system SHALL support the
management of research study
protocols.
3. The system SHOULD support
interactions with other systems,
applications, and modules to enable
participation in research studies
(function S3.3.1)
4. The system SHOULD support the
management and tracking of
patients participating in research
studies.
5. The system MAY support capture of
appropriate details of resident
condition and response to treatment
as required for patients enrolled in
research studies.
6. The system SHALL support
standard report generation (function
S.2.2.2)
1. The system SHALL check for
interactions between prescribed
drugs and medications on the
current medication list..
2. The system SHALL allow the user to
prescribe a medication despite alerts
for interactions and/or allergies
being present.
3. The system MAY have the ability to
set the severity level at which
warnings should be displayed.
4. The system MAY check for duplicate
therapies.
5. The system MAY provide a means
for a provider to document why they
chose to override a drug interaction
warning.
6. The system SHOULD check for
interactions between prescribed
drugs and food detailing changes in
a drug's effects caused by food
(including beverages) consumed
during the same time period.
7. The system SHOULD check for
drug-lab interactions, to indicate to
the prescriber that certain lab test
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
32
Patient specific dosing
and warnings
Identify and present
appropriate dose
recommendations
based on patientspecific conditions
and characteristics at
the time of edication
ordering.
The clinician is alerted
to drug condition
interactions and
patient
specific
contraindications and
warnings e.g. elite
athlete
pregnancy, breastfeeding or
occupational risks,
hepatic or
renal insufficiency. The
preferences of the
patient may
also be presented e.g.
reluctance
to use an antibiotic.
Additional
patient parameters,
such as age,
gestation, Ht, Wt, BSA,
Medication
recommendations
Recommend
treatment and
monitoring on the
basis of
cost, local
formularies or
therapeutic
guidelines and
protocols.
Offer alternative
treatments on the
basis of best practice
standards
(e.g. cost or adherence
to
guidelines), a generic
brand, a
different dosage, a
different drug,
or no drug (watchful
waiting).
Suggest lab order
results may be impacted by a
patient’s drugs.
8. The system SHOULD allow
checking of medications against a
list of drugs noted to be ineffective
for the patient in the past.
9. The system SHALL identify
contraindications between drugs
across patient conditions at the time
of medication ordering
1. The system SHALL conform with
function DC.2.3.1.1
2. The system SHALL identify specific and
appropriate drug dosages for each patient
condition at the time of medication ordering.
3. The system SHALL identify contraindications
between drug
dosages across patient conditions at
the time of medication ordering.
4. The system SHALL identify specific
and appropriate drug dosages based
on each patient parameter at the
time of medication ordering
5. The system SHALL alert the
clinician if an inappropriate drug
dosage does not match the patient’s
parameters at the time of medication
ordering.
6. The system SHALL prevent confirmation of a
drug order until the clinician documents reasons
for overriding a drug alert or warning at the time
of ordering.
7. The system MAY provide override
reasons to the pharmacy so that
communication can occur between
the clinician and the pharmacist.
1. The system SHALL conform with
DC 2.3.1.2.
2. The system SHALL recommend
medication regimen based on
findings related to the patient
diagnosis.
3. The system SHALL offer alternative
treatments in medications on the
basis of practice standards, cost,
formularies, and protocols.
4. The system SHOULD suggest lab
order monitoring as appropriate to a
particular medication.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
Support for medication
and immunization
administration
Alert providers to
potential
administration errors
(such as wrong
patient, wrong drug,
wrong dose, wrong
route and wrong
time) in support of
safe and accurate
medication
administration and
support medication
administration
workflow.
33
monitoring as
appropriate. Support
expedited
entry of series of
medications that
are part of a treatment
regimen,
i.e. renal dialysis,
Oncology,
transplant medications,
etcetera.
To reduce medication
errors at the time of
administration of a
medication, the patient
is positively identified;
checks on the drug,
the dose, the route and
the time are facilitated.
Documentation is a byproduct of this
checking;
administration details
and additional patient
information, such as
injection site, vital
signs, and pain
assessments, are
captured.
Access to drug
monograph information
may be provided to
allow providers to
check details about a
drug and enhance
patient education.
Workflow for
medication
administration is
supported through
prompts and reminders
regarding the “window”
for timely
administration of
medications.
The system SHALL present information
necessary to correctly identify the patient and
accurately administer medications and
immunizations including patient name and
medication name, strength, dose, route and
frequency.
The system SHOULD alert providers to potential
administration errors such as wrong patient,
wrong drug, wrong dose, wrong route and wrong
time as it relates to medication and
immunizations administration.
The system SHOULD alert providers to potential
medication administration errors at the point of
medication administration.
If the system supports medication
administration, the system SHALL capture all
pertinent details of the medication administration
including medication name, strength, dose, route
time of administration and administrator of the
medication.
If the system supports immunization
administration, the system SHALL capture the
administrator of the immunization and the
immunization information identified in DC.1.3.3,
Conformance Criteria #1.
The system SHOULD support capture of other
clinical data pertinent to the medication
administration (e.g. vital signs, pain
assessments).
The system MAY generate documentation of
medication or immunization administration as a
byproduct of verification of patient, medication,
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
34
dose, route and time.
The system SHOULD support medication
administration workflow through prompts or
reminders regarding the “window” for timely
administration of medications.
EDC.2.2
F
Problem List
Retrieval/Management
EDC.2.3
H
Clinical Pathways
EDC.2.3.1
H
EDC.2.3.1.1
F
Order Set
Management
Customize Order Sets
EDC.2.3.1.2
F
Individual Order Sets
Provide a tailored
problem list for
presenting problems.
Provide a means to
create and deliver
clinical pathways for
selected problems.
Provide a means for
organization to
create customized
order sets.
Provide a means for
individual
practitioners to
customize order sets.
Individual order sets are not recommended
Should probably be
able to do this on the
fly.
Edit order set en-masse.
Guide selection of orders.
EDC.2.3.2
F
Presentation Specific
Pathways
EDC.2.4
F
Real-Time Risk
Warnings
System shall
support multiple
workflows.
Risk management at time of data input and
collection.
Real-time prompts based upon chief complaints
or specific granular elements of history and
physical examination.
Abnormal vital signs. Abnormal tests
Non-documented results.
Decision support
Services
Interoperability with single source knowledge
bases, guidelines, et al. throughout the
enterprise.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
35
Standard format and interface definition to
exchange order sets.
Antibiogram
Real time risk analysis for specific diagnoses.
EDC.2.5
F
Sentinel Event Flag
Provide means to
automatically capture
and document errors
and issues for
department analysis,
administrative
review, and systemic
error reduction
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
36
Supportive
Functions
ESP.1
H
Clinical Support
Many of the following functions were moved from Direct Care.
Note that in the EHR – FM there are three sub-sections that have been created here.
ESP.1.1
H
Department Modeling
and Room
Management
Describe ED
physically and
organizationally.
Provide means to
describe ED physically
and organizationally,
including departments,
rooms, holding areas.
The system shall allow for Room/Department
Management.
The system shall/should allow for the
management of holding areas.
The system shall/should provide for the
management of rooms containing multiple
patients.
The system shall/should provide for the
management of room availability
The system shall provide for the management
of patient placement.
EDC.1.1.1
EDC.1.1.2
F
F
Manage room
availability
Manage patient
placement
Flag room status or
availability
Provide a means for
the mechanics of
patient placement,
including overviews
of the department,
waiting room, and
other areas for which
status is of
importance. Allow,
permit, and facilitate
relevant
communications,
notifications,
Provide means for
providers to flag rooms
as reserved, clean,
dirty, biohazard, etc.
ED Flow is dependent
on readying new
rooms, changing linen,
and making the room
availability known.
This is the key piece of
asynchronous
distributed
communication that
was provided for
decades by the grease
board.
The system should provide a means to flag
room status as reserved, in need of cleaning, or
other status.
This may be a
new function. I
can’t seem to find
a similar function
in the EHR-FM.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
37
movement.
EDC.1.1.5.3
F
Manage holding areas
Create holding areas
as needed
EDC.1.1.5.4
F
Manage Multiple
patients in a single
room
Allow/prohibit
multiple patients in
single room
EDC.1.1.5.5
F
Manage Hallway
Patients
Allow for the
management of
patients in hallways,
as well as the
creation, dissolution
of bed status in
hallways and other
“temporary” locations
Manage Admissions to
Hospital from ED.
ESP 2
Measurement,
Analysis, Research
and Reports
ESP 3
Administrative and
Financial
Billing
ESP.3.1.3
F
Administratively
determine a-priori if
multiple patients are
permitted in a
particular room…. This
is a room level
function. That is, some
rooms may and others
may not allow multiple
patients.
Necessary, of course.
The system should provide means to hold
patients in EDIS for unique reasons, including
out of department, other departments, etc.
The system shall allow multiple patients to be in
a single room.
This may not be
too critical. may
not rise to the
level of a
function…
The system shall allow for the management of
hallway patients.
Support for unique
needs of bed requests,
including service, type
of bed, admitting
attending, isolation,
etc.
Provide means to
create a bill for
patients.
Without extra work by
clinician…
Should we include
all relevant billing
data into this
function.
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
38
Information
Infrastructure
IN.1
EII.2
H
H
IN.3
H
EDC.1.1.3
EDC.1.1.4.1
H
F
EDC.1.1.4.2
F
Security
Health record
information and
management
Identity, registry, and
directory services
Protect Identities
Protect all patient
identities.
(Has to be a better way
to say this.)
Protect individual
patient identity.
Keep patient
identities invisible to
other providers on
public tracking
screens.
Flag patient identity
as confidential to
others.
Create de-identified
view for broadcast in
common areas. Many
EDs design or employ
common displays or
dashboards.
Frequently called
“JCAHCO view”
(Move to II…note that
tracking system needs
special attention for
protection of
identity….Information
Infrastructure...not only
tracking)
Create a flag to
indicate to providers
the need to protect the
identity of patients at
particular risk of harm.
The system shall provide a means to protect
patient identities from other patients, patient
visitors, and non participating healthcare
providers.
The system shall provide a means to flag
patients who require protection of their identity
from others, including family, visitors, and non
participating healthcare providers.
Despite best efforts of
confidentiality, display
should identify patients
at particular risk of
harm during stay (e.g.
domestic violence)
IN.5
H
IN.5.1
H
EDC.1.5.5
H
EDC.1.5.5.1
F
Standards-based
Interoperability
Inbound
Interoperations
Cross Reference
Documents
Use incoming medical
summaries
This will have special
bearing on CDR, CCR,
Moved from DC
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
39
(CDA), and other
medical summary
standards.
EDC.1.5.5.2
H
Use Available patient
reports/data
Find and use relevant
documents related to
patient
EDC.1.5.5.2.1
F
IN.5.2
H
IN.5.2.1
F
Hospital Level
Interoperations
ADT Interface
IN.5.2.2
F
Laboratory Interface
IN.5.2.3
F
Pharmacy Interface
IN.5.2.4
F
Automated Dispensing
Equipment
IN.5.2.5
F
Materials Management
IN.5.2.6
F
Radiology Interface
Bed Request Interface
Support for bar code
registration
IN.5.3
H
Outbound
Interoperations
Structured Document
Support
RHIO Outbound
Functionality
Moved from DC
Review previous
medical records
Reports that are
available in the system
or an interoperable
system (say an HIS –
CDR) should be
searchable, findable,
and usable
Interface with ADT
system
Provide means to
interface EDIS with
hospital-wide ADT
system
The crème-de-la-crème???
Provide means to send
message to automated
dispensing equipment.
(i.e. Pyxis)
Provide means to alert
materials management
system with stock
usage.
Pharmacy system handhelds.
F
F
Electronic Prescribing
The system shall export the ED record in CDA
format.
Export EDIS
Encounter to RHIO
Export prescriptions
to eRx system
Provide means for
provider with
appropriate credentials
to, or automatically
export, data to RHIO
Provide functionality to
transmit prescriptions
electronically.
Moved from DC
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
F
Agency Reporting
F
Primary Care Physician
F
Custom flags
40
Provide for automated
electronic transfer of
selected public health
and surveillance
reports.
Provide means to
electronically transfer
ED care record to
patient’s primary care
physician.
Provide means to
create specifically
formatted or
customized flags or
notes to other clinical
systems.
May be useful prior to
RHIO development.
Examples: medication
changes to CDR, note
to enterprise EHR.
Billing Interface
Facility
Supplies E/M
and
Physician
IN.6
F
Business Rules
Management
IN.7
H
IN.7.1
F
Workflow
Management
Sub-second Response
Time
IN.7.2
F
Asynchronous
Distributed
Communications
Speed of interface is
both an
implementation
element and a
necessity for EHR
adoption.
Must:
Not impair workflow
Not impair patient flow
Exhibit Ease
Communicate state of needed attention in the
ED (e.g. “to be seen”. Is backed up….or “labs
are ready on a bunch of patients)..etc. Don’t see
how this has to do with ADS
EDIS - Functional Profile Emergency Care Special Interest Group – HL7
Appendix A: Glossary of Terms
EHR-S
Electronic health record system
Follow-up
The who, when, and where. and what happens if you don’t.
Pre-arrival Data
Data obtained on a patient prior to arrival in the ED.
41