Fillable SAFER System Interfaces Safety Assurance Factors for EHR (Office of the National Coordinator)

Fill Online, Printable, Fillable, Blank SAFER System Interfaces Safety Assurance Factors for EHR (Office of the National Coordinator) Form

Use Fill to complete blank online OFFICE OF THE NATIONAL COORDINATOR (DC) pdf forms for free. Once completed you can sign your fillable form or send for signing. All forms are printable and downloadable.

SAFER System Interfaces Safety Assurance Factors for EHR (Office of the National Coordinator)

On average this form takes 35 minutes to complete

The SAFER System Interfaces Safety Assurance Factors for EHR (Office of the National Coordinator) form is 38 pages long and contains:

  • 0 signatures
  • 0 check-boxes
  • 138 other fields

Country of origin: US
File type: PDF

U.S.A. forms for Office of the National Coordinator

BROWSE OFFICE OF THE NATIONAL COORDINATOR (DC) FORMS

Related forms
Fill has a huge library of thousands of forms all set up to be filled in easily and signed.
Fill in your chosen form
Sign the form using our drawing tool
Send to someone else to fill in and sign.
find another form
 
SAFER
Safety Assurance Factors
for EHR Resilience
> Table of Contents
> About the Checklist
> Team Worksheet
> About the Practice Worksheets
> Practice Worksheets
Self-Assessment
System Interfaces
General Instructions for the
SAFER Self-Assessment Guides
The SAFER Guides are designed to help healthcare
organizations conduct self-assessments to optimize
the safety and safe use of electronic health records
(EHRs) in the following areas.
▪High Priority Practices
▪Organizational Responsibilities
▪Contingency Planning
▪System Configuration
▪System Interfaces
▪Patient Identification
▪Computerized Provider Order Entry
with Decision Support
▪Test Results Reporting and Follow-up
▪Clinician Communication
Each of the nine SAFER Guides begins with a Checklist
of “recommended practices.” The downloadable SAFER
Guides provide fillable circles that can be used to indicate the
extent to which each recommended practice has been
implemented. Following the Checklist, a Practice Worksheet
gives a rationale for and examples of how to implement each
recommended practice, as well as likely sources of input into
assessment of each practice, and fillable fields to record
team members and follow-up action. In addition to the
downloadable version, the content of each SAFER Guide,
with interactive references and supporting materials, can
also be viewed on ONC’s website at www.healthit.gov/
SAFERGuide.
The SAFER Guides are based on the best evidence
available at this time (2016), including a literature review,
expert opinion, and field testing at a wide range of healthcare
organizations, from small ambulatory practices to large health
systems. The recommended practices in the SAFER Guides
are intended to be useful for all EHR users. However, every
organization faces unique circumstances and will implement
a particular practice differently. As a result, some of the
specific examples in the SAFER Guides for recommended
practices may not be applicable to every organization.
The SAFER Guides are designed in part to help deal with
safety concerns created by the continuously changing
landscape that healthcare organizations face. Therefore,
changes in technology, practice standards, regulations and
policy should be taken into account when using the SAFER
Guides. Periodic self-assessments using the SAFER Guides
may also help organizations identify areas in which it is
particularly important to address the implications of change for
the safety and safe use of EHRs. Ultimately, the goal is to
improve the overall safety of our health care system.
The SAFER Guides are not intended to be used for legal
compliance purposes, and implementation of a recommended
practice does not guarantee compliance with HIPAA, the
HIPAA Security Rule, Medicare or Medicaid Conditions of
Participation, or any other laws or regulations. The SAFER
Guides are for informational purposes only and are not
intended to be an exhaustive or definitive source. They do not
constitute legal advice. Users of the SAFER Guides are
encouraged to consult with their own legal counsel regarding
compliance with Medicare or Medicaid program requirements,
HIPAA, and any other laws.
For additional, general information on Medicare and Medicaid
program requirements, please visit the Centers for Medicare
& Medicaid Services website at www.cms.gov. For more
information on HIPAA, please visit the HHS Office for Civil
Rights website at www.hhs.gov/ocr.
July 2016
SAFER Self-Assessment | System Interfaces
1 of 29
SAFER
Safety Assurance Factors
for EHR Resilience
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Self-Assessment
System Interfaces
Introduction
The System Interfaces SAFER Guide identifies
recommended safety practices intended to optimize the
safety and safe use of system-to-system interfaces
between EHR-related software applications. Many
healthcare organizations are involved in planning,
implementing, or maintaining enterprise- or community-
wide clinical information systems that require integration.
1
Such integration occurs most often via interfaces
between software applications, often from different
system developers. These interfaces send and receive
information, enabling disparate systems to operate on
the same data.
System interface projects are complex because
they involve many stakeholders (e.g., clinicians,
administrators, and information technologists in various
departments), often with differing agendas. Stakeholders
must work with hardware devices and software
applications that are developed independently, while
integrating them flawlessly with complex clinical work
processes. Well-designed and well-developed system
interfaces enable reliable physical and logical connection
of different systems. System interfaces require physical
equipment (e.g., hardware such as plugs, cables, and
cards), software that controls the data and information
exchanged, and concepts (e.g., data protocols and
controlled vocabularies that control the interactions
between systems). In addition to these technical issues,
interfaces involve social and organizational factors, such
as agreements to provide data in a consistent format and
to use data to refer to concepts in a consistent manner
(i.e., multiple systems must manage and coordinate any
change to the meaning of a data item). Processes and
preparations must be in place to ensure appropriate
configuration and maintenance of interfaces.
2
For
example, a mapping error between the order entry
system and the pharmacy can cause dispensing of the
wrong drug.
3
Similarly, researchers have identified errors
in the transmission of free-text comment fields between
the order entry application and the pharmacy system.
4
Completing the self-assessment in the System Interfaces
SAFER Guide requires the engagement of people both
within and outside the organization (such as EHR
technology developers). Because this guide is designed
to help organizations prioritize interface-related safety
concerns, including the meaning of the data in the
EHR, clinician leadership in the organization should be
engaged in assessing whether and how any particular
recommended practice affects the organization’s ability to
deliver safe, high quality care. Collaboration between
clinicians and staff members while completing the self-
assessment in this guide will enable an accurate
snapshot of the organization’s system interface status (in
terms of safety), and even more importantly should lead to
a consensus about the organization’s future path to
optimize EHR-related safety and quality: setting priorities
among the recommended practices not yet addressed,
ensuring a plan is in place to maintain recommended
practices already in place, dedicating the required
resources to make necessary improvements, and working
together to prevent and mitigate the highest priority
interface-related safety risks introduced by the EHR.
July 2016
SAFER Self-Assessment | System Interfaces
2 of 29
SAFER
Safety Assurance Factors
for EHR Resilience
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Self-Assessment
System Interfaces
Table of Contents
General Instructions
Introduction
About the Checklist
Team Worksheet
About the Recommended
Practice Worksheets
1
2
4
7
8
The SAFER Self-Assessment Guides were developed by health IT safety researchers and informatics experts:
Joan Ash, PhD, MLS, MS, MBA, Professor and Vice Chair, Department of Medical Informatics and Clinical Epidemiology, School of Medicine,
Oregon Health & Science University;
Hardeep Singh, MD, MPH, Associate Professor of Medicine at the Michael E. DeBakey Veterans Affairs Medical Center and Baylor College of Medi-
cine and Chief of the Health Policy, Quality and Informatics Program at the Houston VA HSR&D Center of Excellence, and Director of the Houston VA
Patient Safety Center of Inquiry; and
Dean Sittig, PhD, University of Texas School of Biomedical Informatics at Houston, UT–Memorial Hermann Center for Healthcare Quality & Safety.
This guide was developed under the contract Unintended Consequences of Health IT and Health Information Exchange, Task Order HHSP23337003T/HHSP23320095655WC.
The ONC composite mark is a mark of the U.S. Department of Health and Human Services. The contents of the publication or project are solely the responsibility of the authors and do not necessarily represent the
official views of the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology.
July 2016
SAFER Self-Assessment | System Interfaces
3 of 29
SAFER
Self-Assessment
System Interfaces
About the Checklist
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
The Checklist is structured as a quick way to enter and print your self-assessment.
Your selections on the Checklist will automatically update the related section of
the corresponding Recommended Practice Worksheet.
The Domain associated with the Recommended Practice(s) appears at
the top of the column.
Self Assessment
SAFER
5 of 17
Contingency Planning
SAFER Self Assessment | Contingency Planning
December xx, 2013
Checklist
>Table of Contents >About the Checklist >Team Worksheet >About the Practice Worksheets
>Practice Worksheets
The Recommended
Practice(s) for the
topic appear below
the associated
Domain.
Select the level
of Implementation
achieved by your
organization for
each Recommended
Practice.
Your Implementation
Status will be
reflected on the
Recommended
Practice Worksheet
in this PDF.
To the right of each Recommended Practice is a link to
the Recommended Practice Worksheet in this PDF.
The Worksheet provides guidance on implementing the
Practice.
July 2016
SAFER Self-Assessment | System Interfaces
4 of 29
SAFER
Self-Assessment
System Interfaces
Checklist
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practices for Domain 1 — Safe Health IT
1.1
The EHR supports and uses standardized protocols for
exchanging data with other systems.
Worksheet 1.1
Implementation Status
Fully
in all areas
Partially
in some areas
Not
implemented
reset
1.2
Established and up-to-date versions of operating
systems, virus and malware protection software,
application software, and interface protocols are used.
Worksheet 1.2
1.3
System-to-system interfaces support the standard
clinical vocabularies used by the connected
applications.
Worksheet 1.3
1.4
System-to-system interfaces are properly configured
and tested to ensure that both coded and free-text data
elements are transmitted without loss of or changes to
information content.
Worksheet 1.4
1.5
The intensity and the extent of interface testing is
consistent with the technical complexity of the
interface and with the importance of the accuracy,
timeliness, and reliability of the data that traverses
the interface.
Worksheet 1.5
1.6
At the time of any major system change or upgrade that
affects an interface, the organization implements
procedures to evaluate whether users (clinicians or
administrators) on both sides of the interface correctly
understand and use information that moves over the
interface.
Worksheet 1.6
1.7
Changes to hardware or software on either side of the
interface are tested before and monitored after go-live.
Worksheet 1.7
1.8
There is a hardware and software environment for
interface testing that is physically separate from the live
environment.
Worksheet 1.8
1.9
Policies and procedures describe how to stop and
restart the exchange of data across the interface in an
orderly manner.
Worksheet 1.9
reset
1.10
Security procedures, including role-based access, are
established for managing and monitoring key
designated aspects of interfaces and data exchange.
Worksheet 1.10
reset
reset
reset
reset
reset
reset
reset
reset
July 2016
SAFER Self-Assessment | System Interfaces
5 of 29
SAFER
Self-Assessment
System Interfaces
Checklist
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
Recommended Practices for Domain 2 — Using Health IT Safely
2.1
The organization has access to personnel with the
skills required to configure, test, and manage all
operational system-to-system interfaces.
Worksheet 2.1
2.2
Administrative, financial, and clinical data exchange
needs are clearly documented and include how data
will be used and who is responsible for maintaining the
interface and the systems connected to it.
Worksheet 2.2
2.3
The organization responsible for managing clinical
content notifies people involved in maintenance or
use of system interfaces when changes are made
that affect the content of the standard data files or
allowable values transmitted via the interface
(e.g.,orderable catalog or charge master).
Worksheet 2.3
2.4
The operational status of the system interface is clear
to its users with regard to clinical use, such as knowing
when the interface cannot transmit or receive
messages, alerts, or crucial information.
Worksheet 2.4
2.5
The interface is able to transmit contextual information,
such as units for measures or sources of information, to
enable clinicians to properly interpret information.
Worksheet 2.5
2.6
Interface problems associated with known system
interface risks and data field size limits are managed to
avoid readily preventable errors.
Worksheet 2.6
Recommended Practices for Domain 3 — Monitoring Safety
3.1
The organization monitors the performance and use of
system interfaces regularly, including monitoring the
interface error log and the volume of transactions over
the interface.
Worksheet 3.1
3.2
> Practice Worksheets
Implementation Status
Fully
in all areas
Partially
in some areas
Not
implemented
reset
When interface errors are detected, they are reported,
fixed, and used to construct new test cases to improve
the interface testing.
Worksheet 3.2
reset
Implementation Status
Fully
in all areas
Partially
in some areas
Not
implemented
reset
reset
reset
reset
reset
reset
July 2016
SAFER Self-Assessment | System Interfaces
6 of 29
SAFER
Self-Assessment
System Interfaces
Team Worksheet
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
A multidisciplinary team should complete this self-assessment and evaluate potential health IT-related patient safety risks addressed by
this specific SAFER Guide within the context of your particular healthcare organization.
This Team Worksheet is intended to help organizations document
the names and roles of the self-assessment team, as well as
individual team members’ activities. Typically team members will
be drawn from a number of different areas within your
organization, and in some instances, from external sources. The
suggested Sources of Input section in each Recommended
Practice Worksheet identifies the types of expertise or services to
consider engaging. It may be particularly useful to engage specific
clinician and other leaders with accountability for safety practices
identified in this guide.
The Worksheet includes fillable boxes that allow you to document
relevant information. The Assessment Team Leader box allows
documentation of the person or persons responsible for ensuring
that the self-assessment is completed. The section labeled
Assessment Team Members enables you to record the names of
individuals, departments, or other organizations that contributed to
the self-assessment. The date that the self-assessment is
completed can be recorded in the Assessment Completion Date
section and can also serve as a reminder for periodic
reassessments. The section labeled Assessment Team Notes is
intended to be used, as needed, to record important
considerations or conclusions arrived at through the assessment
process. This section can also be used to track important factors
such as pending software updates, vacant key leadership
positions, resource needs, and challenges and barriers to
completing the self-assessment or implementing the
Recommended Practices in this SAFER Guide.
Assessment Team Leader
Assessment Completion Date
Assessment Team Members
Assessment Team Notes
reset page
July 2016
SAFER Self-Assessment | System Interfaces
7 of 29
SAFER
Self-Assessment
System Interfaces
About the Recommended
Practice Worksheets
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Each Worksheet provides guidance on implementing a specific Recommended
Practice, and allows you to enter and print information about your self-assessment.
Self Assessment
Contingency Planning
SAFER
Recommended Practice 4
Worksheet
Phase 1 —
Safe Health IT
>Table of Contents >About the Checklist >Team Worksheet >About the Practice Worksheets
>Practice Worksheets
The Rationale
section provides
guidance about
“why” the safety
activities
are needed.
Enter any notes
about your self-
assessment.
Enter any follow-
up activities required.
Enter the name of the
person responsible
for the follow-up
activities.
The Suggested
Sources of Input
section indicates
categories of
personnel
who can provide
information to help
evaluate your level of
implementation.
The Examples
section lists
potentially useful
practices or
scenarios to inform
your assessment and
implementation of the
specific
Recommended
Practice.
July 2016
SAFER Self-Assessment | System Interfaces
8 of 29
reset page
Recommended Practice 1.1
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1
.
1
The EHR supports and uses standardized protocols
for exchanging data with other systems.
5
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Standards, such as those developed by HL7, greatly
simplify the establishment and maintenance of safe and
effective interfaces between EHRs and external systems
(e.g., ancillaries such as laboratory, radiology, or
pharmacy), thereby reducing communication errors.
Suggested Sources of Input
Clinicians, support staff, and/or
clinical administration
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ At a minimum, the EHR satisfies ONC’s certification
requirements related to electronic exchange of information.
▪ The EHR is capable of sending and receiving clinical and
administrative data using HL7 version 2.x messages where
the sending and receiving systems use the same version.
▪ The EHR has 2-way, HL7 v 2.x-compatible interfaces to
mission critical, relevant ancillary data systems (e.g.,
pharmacy, laboratory, blood bank, and radiology).
▪ The EHR is capable of generating, exporting, importing,
and decoding clinical patient summary documents encoded
in the Continuity of Care Document (CCD - R2) standard.
6
This includes procedures such as placing the correctly
decoded clinical data into the proper location in the EHR,
rather than just adding a human-readable version of the
document to the patient’s list of free text reports.
▪ If the organization has an “interface engine," there are
procedures and hardware in place (e.g., redundant servers
and downtime processes) to minimize impact of failure.
7
▪ Both the sending and receiving side of the interfaces are
documented in sufficient detail to allow both sides to
validate the adequacy of the interface for use.
8
▪ The organization has configured the EHR's InfoButton
functionality to link to the most relevant external clinical
information reference resources for their end-users.
9
▪ When sending data across the Internet or other public
networks, the EHR uses a secure, encrypted, transmission
protocol (e.g., SSL - Secure Sockets Layer or TSL -
Transport Layer Security) to ensure the data’s security
while in transit (e.g., when sending a prescription to an
outside pharmacy via Surescripts).
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
9 of 29
SAFER
Self-Assessment
System Interfaces
Off
reset page
Recommended Practice 1.2
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.2
Established and up-to-date versions of operating systems, virus
and malware protection software, application software, and
interface protocols are used.
10
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Failure to stay up-to-date with the latest versions of
software and interface protocols places the organization at
risk of clinical and administrative data loss, corruption, or
theft.
Suggested Sources of Input
Diagnostic services EHR
developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ The organization has policies and procedures to determine
how soon version testing and implementation will occur
after the release of new software.
▪ The organization has employees or service providers
responsible for monitoring and upgrading software and
communication protocols as needed.
▪ Operating systems, virus and malware protection software,
application software, and interface protocols in use are
supported by their suppliers.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
10 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.3
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.3
System-to-system interfaces support the standard clinical
vocabularies used by the connected applications.
11
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Use of standard clinical vocabularies is essential to ensure
semantic interoperability (i.e., consistent interpretation of
the meaning of terms) between systems.
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ The interface supports standard clinical vocabularies and
there are procedures in place to encourage clinical users
to enter data in codified fields using clinical vocabularies
from ONC’s certification requirements, for example:
RxNorm for medication names,
12
SNOMED-CT for
clinical problems,
13
and LOINC for laboratory tests.
14
▪ Interfaced business partners are encouraged to support
and transmit data using current ONC-approved specified
standards.
▪ A process is in place to ensure that standard clinical
vocabularies are updated and consistent in all interfaced
software applications.
▪ Organizations evaluate interfaced software prior to
purchase to ensure that it uses compatible versions of
standard clinical vocabularies.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
11 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.4
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.4
System-to-system interfaces are properly configured and tested
to ensure that both coded and free-text data elements are
transmitted without loss of or changes to information content.
15
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Maintaining a system-to-system interface within a rapidly
evolving clinical information system environment is challenging,
in part because many changes are required. Without the ability
to implement and test these changes prior to go-live, and a
consistent practice of doing so, a healthcare organization would
be placed at significantly increased risk of data loss, corruption,
or theft, which could negatively impact patient safety. Failure to
test system interface components is one of the leading causes
of EHR-related patient safety events.
16
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ System-to-system interfaces are tested before going into
production and after changes to hardware, software, or
content (e.g., the allowable list of data elements to be
exchanged) on either side of the interface.
▪ Free text data fields accessible to clinical end users of
one system are transferred without corruption or
truncation of characters to the other system.
17
▪ Free text data fields that are not supported by the system-
to-system interface should be avoided, if at all possible,
and clearly marked as such for all users if they exist.
▪ The organization (or interface developer) should develop
a reference or validation data set that includes boundary
cases (i.e., data that are slightly below, at, and slightly
above key thresholds). These test data are run through
the interface repeatedly after any change to the hardware
or software on either end of the interface to document
that the interface is continuing to work appropriately.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
12 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.5
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.5
The intensity and the extent of interface testing is consistent
with the technical complexity of the interface and with the
importance of the accuracy, timeliness, and reliability of the
data that traverses the interface.
18
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
While ideally everything should be carefully tested, the
demands of testing must also be reasonable. The
more important the data is to patient safety, the more
interface testing should be conducted.
Suggested Sources of Input
Clinicians, support staff, and/or
clinical administration
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ When testing an interface, both anticipated and
unanticipated types of data (e.g., text characters in a
numeric field) and amounts of data should be used to
ensure that the interface does not respond incorrectly in
either case.
▪ Organizations, through policies and/or job descriptions,
address responsibility for evaluation of the intensity and
extent of interface testing for all new software purchases
or upgrades of systems that must be interfaced.
▪ Organizations address the role of EHR technology
developers in the testing of interfaces, and incorporate
expectations in contractual and service obligations.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
13 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.6
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.6
At the time of any major system change or upgrade that affects an interface,
the organization implements procedures to evaluate whether users
(clinicians or administrators) on both sides of the interface correctly
understand and use information that moves over the interface.
19
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
At the time of major system changes, social factors
can interact with technical factors to create new risks.
Information, even when correctly encoded and
transmitted, can be misinterpreted because of
differences in how users conceptualize their work.
Suggested Sources of Input
Clinicians, support staff, and/or
clinical administration
Diagnostic services
EHR developer
Health IT
support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
▪ Testing uses a wide range of cases and scenarios
including those where users of the external application or
users in the external facility or service may interpret things
differently (e.g., “day” may mean different things to a 24/7
facility and a 9-5 facility; and “home phone” means
different things to a college campus clinic, a nursing
home, an urban “safety net” community clinic, and a
private physician practice).
▪ When a new system is connected or integrated, testing
includes looking for ways that correctly transmitted and
coded information could nevertheless be misinterpreted.
For example, in the first few weeks of using a newly
integrated system, staff is designated to observe use of
the software or to talk to users (in person or by phone) to
confirm the receipt and intended interpretation and use of
information and messages sent via the interface.
20
▪ Testing should include real-world, clinical scenarios of
information exchange, such as: schedule an appointment;
admit a patient; place an order; process order in ancillary
lab; report results; record medication administration.
21
July 2016
SAFER Self-Assessment | System Interfaces
14 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.7
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.7
Changes to hardware or software on either side of the
interface are tested before and monitored after go-live.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Hardware and software updates are inevitable. If the
new hardware or software is unable to handle the load of
transactions or otherwise work as intended in the actual
workplace, it may shut down or compromise data
integrity.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ Upgrades to EHR and ancillary systems are supported by
additional testing of the system-to-system interfaces
involved.
▪ The organization carries out “load testing” (e.g., run a large
number of transactions through the interface in a short
period of time), and “stress testing” (e.g., send erroneous
random data through the interface to potentially induce
unexpected outputs) to ensure that the system can handle
the required load at peak times and when confronted with
erroneous data.
22, 23
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
15 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.8
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.8
There is a hardware and software environment for interface testing that
is physically separate from the live environment.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
EHRs and the many applications they must interface with
are continually changing. System administrators and
application developers need a “safe” place to develop and
test these changes without fear of causing harm to patients.
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ Changes to applications (or the content to be exchanged)
on either side of the interface, or to the interface itself, are
implemented and tested in the test/development
environment before going live (being put into
production).
24
▪ Develop and test batch processing jobs for applications
and interfaces.
▪ Regression testing (i.e., to ensure that all previous
functionality is still working appropriately) is conducted in
the test environment before changes are promoted to the
production system.
25, 26
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
16 of 29
SAFER
Self-Assessment
System Interfaces
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 1.9
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.9
Policies and procedures describe how to stop and restart the exchange
of data across the interface in an orderly manner.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Failure to stop and restart an interface properly can
result in “in transit” data being lost or corrupted
without any warning to users.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ Ensure that all system interface buffers are empty prior to
stopping or restarting the system.
▪ If the interface must be disconnected while the sending
system continues to produce data for transmission (e.g.,
lab tests ordered through CPOE), the buffers are of
adequate size and behavior to prevent any loss of data.
▪ The organization has a method of communicating to
users when a clinical interface is not functioning properly
(e.g., an alert on the login page, or a user-appropriate
alert in the EHR whenever data retrieval or transmission
is attempted but not completed).
▪ Ensure reliable procedures are in place and used for
stopping and starting system interfaces. The procedures
are available and consulted during hardware/software
upgrades.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
17 of 29
reset page
Recommended Practice 1.10
Worksheet
Domain 1 —
Safe Health IT
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
1.
10
Security procedures, including role-based access, are
established for managing and monitoring key designated
aspects of interfaces and data exchange.
27
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
The integrity and confidentiality of data within
applications must be well-protected. When data moves
between systems there is an increased risk of data loss,
corruption, or theft. Both physical and logical security
controls are required over this exchange of data to
prevent unintended changes.
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ The server hosting the interface hardware and software is
maintained in a physically secure (i.e., locked room)
location.
28
▪ The server hosting the “interface engine” has a secure
administrator login to prevent unauthorized changes to
the interface configuration or access to the data as it
crosses the interface.
▪ System security is tested to ensure that unauthorized
individuals or applications cannot alter or gain access to
protected health information.
▪ The security procedures identify and protect key
designated aspects of the interfaces, including content
mapping applications,
27
the content maps themselves,
error logs, and clinical data.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
18 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.1
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.1
The organization has access to personnel with the skills required to
configure, test, and manage all operational system-to-system interfaces.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Configuring, testing, and managing system-to-system
interfaces are complex tasks. The organization must
ensure that only certified or qualified personnel are
assigned to configure, test, and manage the system
prior to go-live.
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ System and application operator manuals for quick
reference are developed, readily available, and up-to-date.
▪ Assigned personnel are trained on all system-to-system
interface maintenance and monitoring activities, or have
appropriate access to qualified personnel.
▪ The organization identifies who is able to access help from
the EHR developer and other external experts.
▪ The organization has a plan for getting access to key
individuals during off-hours (i.e., after routine business
hours and on weekends and holidays).
▪ Training or certification of personnel assigned to configure,
test, and manage interfaces is reviewed on a regular basis, at
least annually, to ensure staff is adequately trained and
afforded the opportunity to update training.
29
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
19 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.2
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.2
Administrative, financial, and clinical data exchange needs are clearly
documented and include how data will be used and who is responsible
for maintaining the interface and the systems connected to it.
30
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Failure to document the business needs and
responsibilities for the interface can result in
miscommunication regarding the meaning and timing
of the exchange of information and lead to patient
harm.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ All types of data to be exchanged via the interface are
clearly specified including: allowable values (e.g., text vs.
numeric, length or size of fields); clinical vocabularies used;
and how associated values (i.e., metadata) will be
communicated (e.g., representation of units on
measurements, sources of data).
▪ The interface is designed to handle the estimated mean
and maximum amounts of data expected to cross the
interface with acceptable performance and errors
generated.
▪ The organization maintains a comprehensive data
dictionary that includes, for each data element:
31
▪ Data type (e.g., coded, text, numeric)
▪ Data definition
▪ Metadata (e.g., creator, date created, users)
▪ The organization maintains a comprehensive interface data
map that includes data recodes or conversions, as required.
▪ The organization maintains a set of interface system
performance requirements including the expected
throughput of the system, uptime requirements, and
protocols supported.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
20 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.3
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.3
The organization responsible for managing clinical content notifies people
involved in maintenance or use of system interfaces when changes are made
that affect the content of the standard data files or allowable values
transmitted via the interface (e.g., orderable catalog or charge master).
32
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
EHR-related hardware and software change frequently.
Failure to notify all parties involved in the maintenance or
use of the system interfaces often results in interface
errors. Some of these errors may be subtle and difficult to
identify. Failure to account for and manage the changes
can lead to serious patient safety events.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ Changes are clearly communicated and tested prior
to go-live, including changes to: conversion programs,
interfaces, databases, screens (e.g., length of data entry
or display fields), tables (e.g., data interpretation, numeric
values, times, dates, or text-based data fields), and
vocabularies.
▪ There is documentation that appropriate testing has
occurred after all system modifications.
▪ There is a policy describing configuration control
procedures that includes: who must be notified before any
change is made, who can make the changes, who is
responsible for testing the changes, who is responsible for
approving the changes, and when the changes can be
implemented in the live system.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
21 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.4
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.4
The operational status of the system interface is clear to its users
with regard to clinical use, such as knowing when the interface
cannot transmit or receive messages, alerts, or crucial information.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Users must be notified when the interface between
clinical systems is not functioning properly. Failure to
distinguish between “there are no results” and “the
interface to the system containing the results is not
functioning” could lead to diagnostic or therapeutic delays.
Suggested Sources of Input
EHR developer
Health IT support staff
Examples of Potentially Useful Practices/Scenarios
▪ The user is informed when the interface cannot transmit a
message.
▪ The user is informed when the remote system from which
they are requesting information is unavailable, due to errors
in the interface or the remote system itself.
▪ The user is notified when drug-allergy interaction testing is
performed on local medications or allergies only (e.g.,
interaction checking excludes medications or allergies
identified by remote pharmacies or health information
exchanges).
33
▪ EHR applications that depend on system interfaces should
report the interface status when in use (e.g., while reviewing
imaging studies, the EHR shows the last update time or
current connection with the PACS system).
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
22 of 29
SAFER
Self-Assessment
System Interfaces
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.5
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.5
The interface is able to transmit contextual information, such as
units for measures or sources of information, to enable
clinicians to properly interpret information.
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Failure to transmit the relevant metadata (i.e., context
or details) related to the data, and necessary for its
interpretation, can lead to misunderstandings and
erroneous decisions.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ The interface can transmit the units for measurements along
with the measurements, and the units are stored in
structured data fields (e.g., 175 lbs. or 500 mg).
▪ The interface can transmit information associated with a
particular measure (e.g., fraction of inspired oxygen
accompanies the arterial blood gas results to allow clinicians
to interpret the blood gas values in the proper context).
34
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
23 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 2.6
Worksheet
Domain 2 —
Using Health IT Safely
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
2.6
Interface problems associated with known system interface
risks and data field size limits are managed to avoid
readily preventable errors.
35
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Physical and logical interfaces have limitations.
Failure to acknowledge and plan for these limitations
often results in patient safety events.
36
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ Testing includes examples where the sending system
would be expected to identify and restrict messages
that are not transmittable (e.g., incorrect data type).
▪ The user is notified if what he or she is typing exceeds
the maximum size for either the storage location or the
system-to-system interface.
37
Simply preventing the
user from entering more text without any notification or
explanation is not considered adequate.
▪ The organization has a process for managing and
minimizing known risks associated with interface
problems, such as two systems with different field size
limits. The system with the smaller limit can cause data
to be truncated unless the risk is addressed properly.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
24 of 29
SAFER
Self-Assessment
System Interfaces
reset page
Recommended Practice 3.1
Worksheet
Domain 3 —
Monitoring Safety
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
3.1
The organization monitors the performance and use of system
interfaces regularly, including monitoring the interface error
log and the volume of transactions over the interface.
38
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
System-to-system interfaces are complex and many
of their actions are not directly visible. Extensive
system monitoring is required to help identify and
track hidden errors before they affect patients.
39
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ Procedures should be in place for continuous monitoring
of the system-to-system interface error log. Escalation
policies and procedures are used to ensure that any
failure of the interface is brought to the attention of the
appropriate staff member, investigated, and fixed in a
timely manner (e.g., less than one week).
40
▪ The number of transactions crossing the interface is
monitored to ensure that the number of transactions is
“normal” (e.g., displayed in a control chart showing the
mean and reasonable upper and lower bounds, such as
2 or 3 standard deviations from the mean).
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
25 of 29
reset page
Recommended Practice 3.2
Worksheet
Domain 3 —
Monitoring Safety
> Table of Contents > About the Checklist > Team Worksheet > About the Practice Worksheets
> Practice Worksheets
Recommended Practice
3.2
When interface errors are detected, they are reported, fixed, and
used to construct new test cases to improve the interface testing.
41
Checklist
Implementation Status
Rationale for Practice or Risk Assessment
Failure to fix interface errors in a timely manner can lead
to patient harm or to loss of clinicians’ confidence in the
data.
Suggested Sources of Input
Diagnostic services
EHR developer
Health IT support staff
Pharmacy
Examples of Potentially Useful Practices/Scenarios
▪ After any interface error is detected and fixed, additional
tests are added to the standard set of tests to check for
the same error in future releases.
Assessment Notes
Follow-up Actions
Person Responsible for Follow-up Action
July 2016
SAFER Self-Assessment | System Interfaces
26 of 29
SAFER
Self-Assessment
System Interfaces
SAFER
f
Saf
or EHR R
ety Assur
esilience
ance Factors
References
1. Cliff R. A Systems Implementation Project Planning Guide. (2007). Cliff Consulting.
2. Magrabi, F., Ong, M. S., Runciman, W., & Coiera, E. (2012). Using FDA reports to inform a classification for health
information technology safety problems. Journal of the American Medical Informatics Association, 19(1), 45-53.
3. Sittig, D. F., & Singh, H. (2011). Defining health information technology–related errors: New developments since To Err Is
Human. Archives of Internal Medicine, 171(14), 1281-1284.
4. Singh, H., Mani, S., Espadas, D., Petersen, N., Franklin, V., & Petersen, L. A. (2009). Prescription errors and outcomes
related to inconsistent information transmitted through computerized order entry: a prospective study. Archives of Internal
Medicine, 169(10), 982-989.
5. Sittig, D. F., Wright, A., Ash, J. S., & Middleton, B. (2009, November). A set of preliminary standards recommended for
achieving a national repository of clinical decision support interventions. In AMIA.
6. Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., Biron, P. V., & Shabo, A. (2006). HL7 clinical document
architecture, release 2. Journal of the American Medical Informatics Association, 13(1), 30-39.
7. Kim, H. S., Cho, H., & Lee, I. K. (2011). The Development of a Graphical User Interface Engine for the Convenient Use of
the HL7 Version 2. x Interface Engine. Healthcare Informatics Research, 17(4), 214-223.
8. Wichmann, B., Parkin, G., & Barker, R. (2000). Software support for metrology best practice guide No. 1. National Physical
Laboratory, Middlesex, United Kingdom.
9. Del Fiol, G., Huser, V., Strasberg, H. R., Maviglia, S. M., Curtis, C., & Cimino, J. J. (2012). Implementations of the HL7
Context-Aware Knowledge Retrieval (“Infobutton”) Standard: challenges, strengths, limitations, and uptake. Journal of
Biomedical Informatics, 45(4), 726-735.
10. Sood, A. K., & Enbody, R. J. (2013). Targeted cyberattacks: a superset of advanced persistent threats. IEEE Security &
Privacy, 11(1), 54-61.
11. Deckard, J., McDonald, C. J., & Vreeman, D. J. (2015). Supporting interoperability of genetic data with LOINC. Journal of
the American Medical Informatics Association, 22(3), 621-627.
12. RxNorm Files. (2016). Unified Medial Language System (UMLS). U.S. National Library of Medicine.
13. SNOMED Clinical Terms User Guide. (2016). The International Health Terminology Standards Development Organisation.
14. Forrey, A. W., Mcdonald, C. J., DeMoor, G., Huff, S. M., Leavelle, D., Leland, D., ... & Tullis, A. (1996). Logical
observation identifier names and codes (LOINC) database: a public use set of codes and names for electronic reporting of
clinical laboratory test results. Clinical Chemistry, 42(1), 81-90.
15. ONC Electronic Health Record (EHR) System Testing Plan. (2012). Office of the National Coordinator for Health
Information Technology.
16. Sparnon, E., & Marella, W. M. (2012). The role of the electronic health record in patient safety events. Pennsylvania
Patient Safety Advisory, 9(4), 113-121.
17. Dhavle, A. A., Yang, Y., Rupp, M. T., Singh, H., Ward-Charlerie, S., & Ruiz, J. (2016). Analysis of Prescribers’ Notes in
Electronic Prescriptions in Ambulatory Practice. JAMA Internal Medicine, 176(4), 463-470.
18. Amland, S. (2000). Risk-based testing:: Risk analysis fundamentals and metrics for software testing including a financial
application case study. Journal of Systems and Software, 53(3), 287-295.
19. Klein, C. S. (2003). LIMS user acceptance testing. Quality Assurance: Good Practice, Regulation, and Law, 10(2),91-106.
July 2016
SAFER Self-Assessment | System Interfaces
27 of 29
July 2016
SAFER Self-Assessment | System Interfaces
28 of 29
SAFER
Safety Assurance Factors
for EHR Resilience
References
20. Aarts, J. (2012). Towards safe electronic health records: A socio-technical perspective and the need for incident
reporting. Health Policy and Technology, 1(1), 8-15.
21. Jensen, S., Kushniruk, A. W., & Nøhr, C. (2015). Clinical simulation: A method for development and evaluation of clinical
information systems. Journal of Biomedical Informatics, 54, 65-76.
22. Mostefaoui, G. K., Wilson, G., Ma, X., Simpson, A., Power, D., Russell, D., & Slaymaker, M. (2009). The Development,
Testing, and Deployment of a Web Services Infrastructure for Distributed Healthcare Delivery, Research, and Training.
23. Abel, D., Gavidi, B., Rollings, N., & Chandra, R. (2015). Development of an Android Application for an Electronic Medical
Record System in an Outpatient Environment for Healthcare in Fiji. arXiv preprint arXiv:1503.00810.
24. Wright, A., Aaron, S., & Sittig, D. F. (2016). Testing electronic health records in the “production” environment: an
essential step in the journey to a safe and effective health care system. Journal of the American Medical Informatics
Association, ocw039.
25. Nanda, A., Mani, S., Sinha, S., Harrold, M. J., & Orso, A. (2011, March). Regression testing in the presence of non-code
changes. In 2011 Fourth IEEE International Conference on Software Testing, Verification and Validation (pp. 21-30). IEEE.
26. Carlson, S. D. (2015). Testing in the healthcare informatics environment. Mastering Informatics: A Heatlhcare Handbook
for Success, 61.
27. Smokers prescribed Viagra to quit. (2006, December 13). BBC.
28. Cucoranu, I. C., Parwani, A. V., West, A. J., Romero-Lauro, G., Nauman, K., Carter, A. B., ... & Pantanowitz, L. (2013).
Privacy and security of patient data in the pathology laboratory. Journal of Pathology Informatics, 4.
29. Payne, T., Lovis, C., & Debande, B. (2014). Troubleshooting: what can go wrong and how to fix it. Practical Guide to
Clinical Computing Systems: Design, Operations, and Infrastructure, 242.
30. Mykkänen, J., Porrasmaa, J., Rannanheimo, J., & Korpela, M. (2003). A process for specifying integration for multi-tier
applications in healthcare. International Journal of Medical Informatics, 70(2), 173-182.
31. Wu, Y., Yao, X., Sun, P., Hu, Y., Zhu, Y., & Hu, Y. (2013). Development of community health service-oriented computer-
assisted information system for diagnosis and treatment of respiratory diseases. Family Medicine and Community Health,
1(4), 1-9.
32. Wright, A., Hickman, T. T. T., McEvoy, D., Aaron, S., Ai, A., Andersen, J. M., ... & Bates, D. W. (2016). Analysis of
clinical decision support system malfunctions: a case series and survey. Journal of the American Medical Informatics
Association, ocw005.
33. Byrne, C. M., Mercincavage, L. M., Bouhaddou, O., Bennett, J. R., Pan, E. C., Botts, N. E., ... & Cromwell, T. (2014). The
Department of Veterans Affairs’ (VA) implementation of the Virtual Lifetime Electronic Record (VLER): findings and lessons
learned from Health Information Exchange at 12 sites. International Journal of Medical Informatics, 83(8), 537-547.
34. Baird, G. (2013). Preanalytical considerations in blood gas analysis. Biochemia Medica, 23(1), 19-27.
35. Rinard, M., Cadar, C., Dumitran, D., Roy, D. M., & Leu, T. (2004, December). A dynamic technique for eliminating buffer
overflow vulnerabilities (and other memory errors). In Computer Security Applications Conference, 2004. 20th Annual (pp.
82-90). IEEE.
36. Papp, D., Ma, Z., & Buttyan, L. (2015, July). Embedded systems security: Threats, vulnerabilities, and attack taxonomy.
In Privacy, Security and Trust (PST), 2015 13th Annual Conference on (pp. 145-152). IEEE.
SAFER
f
Saf
or EHR R
ety Assur
esilience
ance Factors
July 2016
SAFER Self-Assessment | System Interfaces
29 of 29
References
37. Um, K. S., Kwak, Y. S., Cho, H., & Kim, I. K. (2005). Development of an HL7 interface engine, based on tree structure and
streaming algorithm, for large-size messages which include image data. Computer Methods and Programs in Biomedicine,
80(2),126-140.
38. Sittig, D. F., & Singh, H. (2012). Electronic health records and national patient-safety goals. New England Journal of Medicine,
367(19), 1854-1860.
39. Beckwith, B. A., Brassel, J. H., & Brodsky, V. B. (2013). Laboratory interoperability best practices: ten mistakes to avoid.
College of American Pathologists.
40. Sittig, D. F., Campbell, E. M., Guappone, K. P., Dykstra, R. H., & Ash, J. S. (2007, October). Recommendations for monitoring
and evaluation of in-patient Computer-based Provider Order Entry systems: results of a Delphi survey. In AMIA.
41. Spillner, A., Linz, T., & Schaefer, H. (2014). Software testing foundations: a study guide for the certified tester exam. Rocky
Nook, Inc.
Download
Save PDF to desktop
Email
Email completed PDF
Send for Signing
Email for others to sign
Print
Print document
Choose a Field
Click on a field and
select the person that should complete it
Want to add a signature?
You can add a signature field
and assign it to someone else
to sign
Choose a Field
Click on a field and
select the person that should complete it

SAFER System Interfaces Safety Assurance Factors for EHR (Office of the National Coordinator)

This document is locked as it has been sent for signing.

You have successfully completed this document.

Other parties need to complete fields in the document. You will recieve an email notification when the document has been completed by all parties.

This document has been signed by all parties.

Completed 26 January 2021

Message

View Audit Log
Print With Audit Log
Duplicate Document