Abstract
Background Secure clinical messaging and document exchange utilizing the Direct Protocol (Direct
interoperability) has been widely implemented in health information technology (HIT)
applications including electronic health records (EHRs) and by health care providers
and organizations in the United States. While Direct interoperability has allowed
clinicians and institutions to satisfy regulatory requirements and has facilitated
communication and electronic data exchange as patients transition across care environments,
feature and function enhancements to HIT implementations of the Direct Protocol are
required to optimize the use of this technology.
Objective To describe and address this gap, we developed a prioritized list of recommended
features and functions desired by clinicians to utilize Direct interoperability for
improved quality, safety, and efficiency of patient care. This consensus statement
is intended to inform policy makers and HIT vendors to encourage further development
and implementation of system capabilities to improve clinical care.
Methods An ad hoc group of interested clinicians came together under the auspices of DirectTrust
to address challenges of usability and create a consensus recommendation. This group
drafted a list of desired features and functions that was published online. Comments
were solicited from interested parties including clinicians, EHR and other HIT vendors,
and trade organizations. Resultant comments were collected, reviewed by the authors,
and incorporated into the final recommendations.
Results This consensus statement contains a list of 57 clinically desirable features and
functions categorized and prioritized for support by policy makers, development by
HIT vendors, and implementation and use by clinicians.
Conclusion Fully featured, standardized implementation of Direct interoperability will allow
clinicians to utilize Direct messaging more effectively as a component of HIT and
EHR interoperability to improve care transitions and coordination.
Keywords
provider–provider communications -
interfaces and usability -
care transition -
health information interoperability -
health information exchange -
user–computer interface -
continuity of care document
Background and Significance
The Direct Standard for secure and interoperable electronic transport of clinically
relevant messages and attachments was developed by the Office of the National Coordinator
for Healthcare Information Technology, an agency of the United States (U.S.) Department
of Health and Human Services, in a public–private partnership during 2010 and 2011
known as the Direct Project.[1] When used by clinicians, hospitals, or others to share clinical content across organizational
and health information technology (HIT) vendor boundaries, the combination of that
content and the use of the Direct Standard is known as “Direct interoperability,”
“Direct messaging,” “Direct exchange,” or sometimes simply “Direct.” Direct interoperability
is a key component of a multiyear U.S. effort to reward clinicians and hospitals for
the “meaningful use” of EHRs and other HIT under the statutory mandates of the law
known as the Health Information Technology for Economic and Clinical Health (HITECH)
Act,[2] enacted as part of the American Recovery and Reinvestment Act of 2009. Under HITECH,
eligible professionals and hospitals are required to meet certain criteria for electronic
exchange of health information to receive incentive payments and to avoid payment
penalties. For example, if a primary care physician refers a patient to a specialist
and sends the patient's Clinical Summary using Direct interoperability, they meet
one of the meaningful use criteria related to transitions of care.
Since its introduction in 2011, use of Direct interoperability to send, or “push”
health information from one provider or organization to another has grown rapidly
and use cases have expanded.[3]
[4]
[5] As of late 2017, there were over 100,000 health care organizations in the United
States with at least one Direct account, and over 1.6 million clinicians and staff
members at these hospitals, medical offices, clinics, long-term care facilities, and
other institutions who can send and receive messages and attachments via Direct interoperability.
Over 350 EHR and personal health record (PHR) products are capable of Direct interoperability.
While care coordination and transitions of care remain among the most common use cases,
secure transport of laboratory and other test results,[6]
[7] sharing of claims attachments, and reporting from EHRs to disease and population
management databases and registries are among the many other uses to which Direct
interoperability is now being put, often replacing fax, electronic fax, mail, and
courier as a preferred transport mechanism.
Secure, interoperable sharing of patients' clinical information improves operational
efficiency and is critically important to patients, clinicians, and care teams involved
in patient care transitions and coordination. This is particularly valuable where
patients are engaged with multiple clinicians from disparate organizations, who utilize
diverse EHRs and other HIT applications. Although most HIT-enabled organizations in
the United States have installed systems with Direct interoperability capabilities,
after years of experience, this valuable functionality remains poorly understood and
underutilized by many clinicians and hospitals. The robust EHR features and functionalities
needed for the optimal use of Direct interoperability remain undeveloped by some HIT
vendors, unimplemented by health care organizations, or unused by clinicians.[8]
[9]
[10] To date, there have been no peer-reviewed journal articles examining the use or usability
of Direct interoperability.
Objective
To address the inadequacies of existing clinical messaging functions in HIT systems,
in November 2016 DirectTrust[11] convened a group of interested clinicians with experience in Direct interoperability
using diverse EHRs and other HIT applications. This group created a list of prioritized
feature and function recommendations intended for the broad EHR and HIT vendor community
to enhance the usability of Direct interoperability.
Methods
A draft list of 51 recommended features and functions was published online on February
1, 2017 with an invitation for public comment.[12] The document was broadly disseminated through HIT media, listserves, and professional
organizations. Comments were accepted via email through April, 2017. Additional input
was collected from vendors and other stakeholders at a Direct Exchange Workshop held
by the Office of the National Coordinator for Health Information Technology in Washington,
D.C., on June 9, 2017. The workgroup reviewed and developed responses to all written
comments during a dozen open online meetings and made multiple changes to its original
recommendations.
The workgroup categorized recommendations by use case, i.e., transitions of care,
clinical messaging, and administrative functions. Recommendations were further segmented,
as appropriate, into “outbound” and “inbound” message functions to offer additional
organization and clarity. The clinical rationale for each recommendation was also
documented. A priority was assigned to each recommendation with “1” as the highest
need, “2” as highly desirable, and “3” indicating anticipated future needs. Finally,
each priority was given a recommended timing, with the highest priority items recommended
for inclusion in the current or next version of HIT products, priority 2 items within
1 to 2 years, and priority 3 thereafter.
Results
One hundred fifty-one comments were received from organizations and individuals representing
10 HIT vendors and 13 U.S. health care provider and payer organizations. One hundred
sixteen (77%) of the comments were from HIT vendors. The workgroup received extensive
feedback focusing on the need to improve the usability of Direct interoperability,
the value of clinical messaging, the critical need for users to be able to trust the
information received, and the technical feasibility and challenges of implementing
the recommendations provided. The comments included broad support for building upon
the success of Direct interoperability as currently implemented by HIT vendors. The
initial recommendations and the feedback resulted in the 57 final recommendations
detailed in [Tables 1]
[2]
[3].
Table 1
Recommendations for transitions of care
|
Priority 1
|
Required/Urgent/Now/Current-next version
|
|
Priority 2
|
Highly desired/Future priority/1–2 y/Subsequent version
|
|
Priority 3
|
Advanced/Future development
|
|
Transitions of care
|
|
Feature/Function
|
Recommendation
|
Rationale
|
Priority
|
|
Outbound message functions
|
|
TO1:
Real-time message delivery
|
Direct interoperability messages are sent in “real time” and are never “batched” for
timed sends
|
The sending of messages in real time, following a patient's transition of care, supports
end users' ability to utilize information for patient care immediately. Clinicians,
who have successfully used Direct, report that receiving the Direct message in “real-time”
as opposed to batch processes allows the receiver to initiate appropriate patient
outreach and follow up immediately preventing patient adverse events. It also allows
patient care and transitional care management to be provided more efficiently
|
1
|
|
TO2:
Direct messages automatically triggered by specific events
|
HIT systems can automatically send Direct messages based on specific triggers (e.g.,
discharge or referral orders)
|
Automated real-time sending of Direct messages ensures that the patient's treating
clinicians are aware of care transitions and are provided with the most current and
up to date information. Timely receipt of messages facilitates information reconciliation
in the recipient systems, helps to prevent unnecessary duplicate testing, and reduces
adverse events. For example, an acute care system can be configured so that when a
patient discharge order is entered this triggers the automated sending of a Consolidated
Clinical Document Architecture (C-CDA) document, or a template of combined C-CDA document
sections to the patient's Primary Care Provider (PCP) and/or ambulatory provider of
record in the system, if a Direct address is available for that clinician. The ambulatory
systems can be configured to send a Direct Message to a specialist triggered by a
PCP's referral order. Similarly, consultants' EHR systems can be configured to send
a Direct Message to the referring provider prompted by a referred patient being seen
and/or the completion of the consultation note
|
1
|
|
TO3:
Automatically send Direct message(s) to provider(s) of record with Direct addresses
in the sending system
|
Once a triggering event occurs, the sending system is able to automatically send a
message to:
– the PCP of record
– the referring physician
– all providers identified as members of the patient's care
team, and/or
– another identified provider, given that the(se) provider(s) have Direct Addresses
|
This recommendation ensures continuity of care with the identified members of the
patient's care team and prevents the blocking of information flow to the patient's
providers across organizational boundaries
|
1
|
|
TO4:
Include patient-specific
attachments
|
The sending facility is able to configure a Direct “template” (see also TO7) that
includes automatically attached document types and/or sections from the sending HIT
system based on the specific clinical scenario. Attachments can include structured
data (e.g., C-CDA, or a template with a combination of C-CDA document types or sections,
spreadsheets); unstructured data (e.g., Word, PDF, or plain text files) and image
files (e.g., JPG and GIF). In addition, providers can attach documents “on the fly”
as needed
|
Direct has been demonstrated to provide a critical capability for information sharing
in support of patient care, which essentially virtualizes the EHR across disparate
HIT systems and health care organizations to support care team access to critical
patient information. Direct messages should support the inclusion of all clinically
relevant document types in support of best practice and efficient care as patients
transition across their medical neighborhoods. The inclusion of a variety of document
types also prevents duplicate testing or gaps in clinical information required for
patient care
|
1
|
|
TO5:
Use HIT industry-wide standardized discrete data terminology for problem, medication,
allergy, immunization data in Direct documents
|
Vendors use all existing recognized standard vocabularies to promote information sharing
across all HIT systems and the ability of the recipient system to readily consume
and reconcile discrete information
Data reconciliation by the sending provider preceding and by the recipient provider
following all care transitions should include all data for which there are discrete
vocabularies including active problems, allergies, medications, and historical immunizations
(PAMI data)
Specific vocabularies (e.g., SNOMED, ICD10, RxNorm, and CVX) should be used to encode
discrete PAMI data as applicable in all C-CDA and other documents sent via Direct
|
Direct interoperability supports the sharing of patient data using standardized data
vocabularies across all EHR vendors. Standardized use and transmission of discrete
data would allow for exceptional end user functionality creating care and documentation
efficiencies and preventing life-threatening transcription errors. These efficiencies
would further promote the desirability and use of Direct messaging and facilitate
medical information reconciliation across the patient's care team. Exchange of discrete
data via Direct, with appropriate pre- and posttransition of care clinician data reconciliation,
can save clinicians documentation time and prevent potentially life-threatening transcription
errors and patient adverse events
|
1
|
|
TO6:
Automated outgoing messages include the “trigger” for sending the message in the message
metadata
|
Automatic outgoing messages' metadata include the “trigger” for sending the automated
message (e.g., hospital discharge or specialty referral)
|
Including information regarding the message trigger in the metadata sent with a Direct
message allows the recipient systems to automatically or manually route and/or prioritize
messages for specific organizational role-based workflows
|
2
|
|
TO7:
Ability to customize C-CDA templates
|
Sending organization are able to configure templates for specific clinical circumstances
such as discharge, referral, specific conditions/diagnoses, or encounter types. Templates
are configurable at the provider or organization level
Templates can be a single or a combination of C-CDA document types or C-CDA document
type sections Examples include:
• A “Discharge Template” could be configured to include a brief clinical summary,
a reconciled discharge problem list, medications, allergies, immunizations, procedures,
first and last instance of any laboratory or test results, imaging studies, operative
notes, vital signs, discharge instructions, etc.
• A “Cardiology Referral Template” could be configured to include the patient's last
clinic note, specific laboratories and studies relevant to cardiology, the patient's
active problems, medications, allergies, immunizations, family, medical, surgical,
and social histories, urgency of request, and request for a specific cardiologist
Templates could be configured either at the provider or organization level. With the
organization having the ability to determine the level (e.g., only allowing templates
to be configured at the organizational level to support organizational standardization).
Appropriate templates could be generated automatically based the message trigger event
(e.g., Cardiology referral or discharge order) the system will automatically assemble
the appropriate template.
|
Template customization allows the organization to preconfigure Direct messages to
include the appropriate information for the next provider caring for the patient.
As a result, messages will include the right information and the right amount of information
and will save the sending clinician time by avoiding the need to collate information
manually for every outgoing Direct message. Having the right amount and most current
patient information may also cause the recipient to attribute greater value to incoming
messages preventing information overload and inaccuracies resulting from outdated
information
|
2
|
|
TO8:
System alert if automated message cannot be sent when the send trigger is invoked
|
The system can issue an alert if the sending of an automated message fails. For example,
a discharge order may trigger an automated discharge message, but the sending of the
message fails because the system lacks a PCP of record or the PCP of record does not
have a Direct address. In this case, the system will alert the provider, or his or
her delegate, whose action (e.g., discharge order) precipitated the trigger event
|
This system alert will ensure that the failure of a Direct message to leave the initiating
system will result in an alert to the clinician, or his or her designee, who can then
initiate an alternative information sharing process (e.g., fax, postal mail, telephone
call, etc.) As health care providers and organizations implement new automated electronic
messaging systems, older communications processes may be left in place leading to
redundant communication via multiple channels with resultant information overload
and decreased attention to information received. The ability to know when an automated
Direct message cannot be sent supports the decommissioning of alternate automated
messaging, such as faxing/mailing result reports or discharge summaries, allowing
these methodologies to be used only in circumstances where a Direct message cannot
be sent
|
2
|
|
TO9:
Use HIT industry-wide standardized discrete data terminology for additional data types
including procedures and laboratory results
|
Vendors will use recognized standardized vocabularies to exchange discrete data beyond
PAMI data types (e.g., LOINC codes for laboratory results and CPT codes for procedures)
to allow information sharing, consumption, and reconciliation across HIT systems
|
This recommendation promotes the exchange and recipient system consumption of discrete
patient data in support of data reconciliation, care efficiency, population health
management, and reduces medical errors and duplicate testing
|
2
|
|
TO10:
Automatically send Direct message to the patient
|
According to the health care organization's protocols and policies and the patient's
wishes, the system may automatically send relevant Direct messages to the patient
if the patient has a Direct address
|
This recommendation allows patients to receive their health information without the
need to visit multiple health care organization linked portals
|
3
|
|
TO11:
Medical societies shall create condition-specific templates for referrals
|
We recommend that specialty-specific medical societies create and share with the health
care community diagnosis and condition-specific templates that include the clinical
information and data elements such as tests and study results to be sent when a patient
is being referred to a specialist, or health care facility with that specific diagnosis
or condition
|
Diagnosis/condition-specific templates specified and supported by medical societies
will assure that specialists receive the appropriate information from referring providers
in a standardized fashion and will prevent information overload by recipient clinicians,
improving the efficiency of care transitions and coordination
|
3
|
|
Inbound message functions
|
|
TI1:
Receive, store and display message attachments in the recipient HIT system
|
In addition to the C-CDA, or a template of combined C-CDA documents and/or document
sections, HIT systems support receipt, storage, and display of a wide variety of attachment
types including:
• structured data (e.g., C-CDA, spreadsheets)
• unstructured data (e.g., Word, PDF)
• plain text files
• image files (e.g., JPG and GIF)
|
Medical information exists in a variety of formats (e.g., structured data, unstructured
data, images, and PDF files). To support efficient care, avoid duplication of tests
and procedures, and reduce information gaps, Direct messages should allow the inclusion
of all clinically relevant document types to support the transition of patients across
their medical neighborhoods. This recommendation discourages vendors from removing
valuable information by stripping attachments from messages
|
1
|
|
TI2:
Automated patient identification
|
All HIT systems automatically match incoming Direct messages with existing patients
in the recipient system. Without a unique patient identifier, systems use their existing
patient matching algorithms. For new patients or patients, who cannot be automatically
matched (e.g., new referral to a specialist, or patient demographic information that
could match to more than one existing patient record); the receiving system will route
the message to a work queue for patient registration and/or manual matching. Incoming
data for matched patients will be stored and available to the designated recipient
and his or her delegate(s)
|
Lack of an automated patient identification/matching service degrades Direct interoperability
to the level of an EHR integrated fax server. Manual patient matching delays Direct
messages from reaching the appropriate user, putting patients at increased risk for
adverse events in the context of care transitions
Depending on HIT functionality, staffing models and volume of Direct messages, delays
from manual matching may exceed 24 hours, putting patients at risk for adverse events.
Patient matching must be automated to prevent impeding data flowing to the intended
recipients, to support information sharing for patient care, and to reduce the risk
of life-threatening complications including adverse drug events
As Direct is adopted for all transitions of care (TOC) and clinical messaging, the
anticipated volume of incoming messages would require additional staff resources if
incoming message patient matching were conducted manually
|
1
|
|
TI3:
Reconciliation of active medications
|
The system supports the reconciliation of active medications Following any patient
care transition, the C-CDA or a template with a combination of C-CDA document types
or sections includes a list of active medications:
• For new patients, the recipient, or his or her delegate(s), can use the medication
list to integrate all medications and associated administration instructions (Sigs)
into the receiving system as discrete, actionable data
• For established patients, the recipient, or his or her delegate(s), can directly
review and compare the received medication list and sig with the medication list and
sig in his/her native HIT system. The provider can then use his/her judgment to perform
medication reconciliation by: discontinuing medications, adding medications, or changing
the dose of medications in his/her system based on medication changes made by the
sending provider. As the receiving user accepts new medications information from a
received C-CDA document into the receiving system, the medication information is transferred
as discrete data with the sig
• Medications that the provider sees on the C-CDA, but does not want the patient
to continue would not be integrated into his or her updated medication list and could
trigger a discontinuation discussion with the patient
|
Pre- and post-transition of care medication reconciliation using discrete data received
via Direct can ensure that recipient clinicians have the most accurate and current
information available for information reconciliation and system data consumption thereby
enhancing care efficiency, saving clinicians' time, resulting in reduced errors, saved
patient lives, and decreased costs
|
1
|
|
TI4:
Reconciliation of active problems
|
The system supports the reconciliation of active problems
Following any patient care transition, the provided C-CDA or a template with a combination
of C-CDA document types, or sections includes an encoded list (e.g., utilizing ICD10
and/or SNOMED codes) of active medical problems/conditions:
• For new patients, the recipient user, or his or her delegate(s) should be able
to integrate this list directly into his/her HIT system as discrete, actionable data
• For established patients, the recipient provider should be able to compare onscreen
the problem list in his/her native system and with the problem list received in the
C-CDA, allowing the provider to perform problem list reconciliation by discontinuing
problems that have been superseded or are inactive or adding new problems to his/her
EHR that are warranted
• Problems in the C-CDA that the providers does not considers active would not be
transferred to the new list and may generate follow-up discussion with the patient
|
Reconciliation of patient problem lists pre- and post-transitions of care using discrete
data exchanged via Direct can improve care efficiency and save clinicians time resulting
in reduced errors and decreased costs
|
1
|
|
TI5:
Reconciliation of allergies
|
The system supports the reconciliation of patient allergies
Following any patient care transition, the received C-CDA or a template with a combination
of C-CDA document types or sections includes an encoded list of the patient's current/active
allergies:
• For new patients, the recipient provider, or his or her delegate(s) should be able
to integrate this list directly into his/her HIT system as discrete, actionable data
• For established patients, the recipient provider should be able to compare onscreen
the allergies list in his/her local system and the allergies list received in the
C-CDA document. The provider can them perform allergy reconciliation
|
Reconciliation of patient allergies pre- and post-transition of care using discrete
data exchanged via Direct can improve care efficiency and save clinicians time resulting
in reduced errors and decreased costs
|
1
|
|
TI6:
Reconciliation of immunizations
|
The system supports the reconciliation of patient immunization histories
Following any patient care transition, the provided C-CDA or a template with a combination
of C-CDA document types or sections includes an encoded list (e.g., utilizing CXV
codes) of the patient's current/active immunizations:
• For new patients, the recipient provider, or his or her delegate(s) should be able
to integrate this list directly into his/her EHR system as discrete, actionable data
• For established patients, the recipient provider should be able to compare onscreen
the immunization list in his/her local EHR and the immunization list received in the
C-CDA. The provider can them perform immunization reconciliation
|
Reconciliation of patient immunization histories pre- and post-transition of care
using discrete data exchanged via Direct can improve care efficiency and save clinicians
time resulting in reduced errors and decreased costs
|
1
|
|
TI7:
Reconciliation of procedures
|
The system supports the reconciliation of patient procedure histories
Following any patient care transition, the provided C-CDA or a template with a combination
of C-CDA document types or sections includes an encoded list (e.g., utilizing CPT
or SNOMED codes) of the patient's past procedures and operations:
• For new patients, the recipient provider (or his or her delegate) should be able
to integrate this list directly into his/her EHR system as discrete, actionable data
• For established patients, the recipient provider should be able to compare onscreen
the procedures and operations (CPT Codes) list in his/her local EHR and the procedures
and operations (CPT Codes) list received in the C-CDA. The provider can them perform
procedure reconciliation
|
Reconciliation of patient procedure and surgical histories pre- and post-transition
of care using discrete data exchanged via Direct can improve care efficiency and save
clinicians time resulting in reduced errors and decreased costs
|
2
|
|
TI8:
Reconciliation of test results
|
Following any patient care transition, the provided C-CDA, or a template with a combination
of C-CDA document types and sections, includes an encoded list of tests or studies
performed and their results (e.g., utilizing LOINC codes for laboratory test result
components and SNOMED codes for other result values):
• For new and established patients, the recipient user, or his or her delegate(s)
should be able to integrate, at their discretion, all or some of these tests and studies
directly into his/her HIT system as discrete, actionable data including but not limited
to laboratory, radiology, gastroenterology, neurology, cardiovascular, and pulmonary
testing. All of the native system functionalities (e.g., being able to compare results,
create flow sheets, and utilize graphing functions) shall be applicable to the data
received
|
Receipt and incorporation of historical laboratory and other test results using discrete
data exchanged via Direct can reduce duplicative testing, improve patient safety and
care efficiency and save clinicians' time resulting in reduced errors, decreased costs,
and improved clinical outcomes.
|
2
|
|
TI9:
Other discrete data exchange and reconciliation
|
As standardized vocabulary use increases in HIT systems, additional standardized data
elements will be included in Direct messages and enabled for reconciliation across
systems. Data may include social, family, and medical histories, genomic data, patient-generated
health data, patient satisfaction, social determinates of health, medical device data,
patient care team members, etc.
|
Direct exchange and reconciliation of additional data types using discrete data can
reduce duplicative testing, improve patient safety and care efficiency, and save clinicians'
time resulting in reduced errors, decreased costs, and improved clinical outcomes
|
3
|
|
TI10:
Recipient configuration of the information viewed from the incoming message (C-CDA)
|
Recipient systems are able to configure the display of information received with an
incoming message Configuration may be specified at the organization or user level
For example, the view of a discharge summary that includes all of the information
from a hospitalization (every vital sign, laboratory test and study, input and output,
etc.) deemed unnecessary by the recipient provider can be configured so that, for
example, only the first and last vital sign and first and last instance of any laboratory
test or study are visible. Configurability assures that the information that is displayed
is limited to the information that the recipient wants to see and is presented to
the user in a consistent manner. The system will also allow the recipient to view
the information that was received but not displayed by default (i.e., drill down)
|
Allowing users to determine which information is most relevant information and to
configure his/her view of the received information facilitates efficient review of
critical information for patient care and enhances the adoption of this technology.
The ability for the recipient user to drill down to other information, if needed,
allows the recipient user to access all information if the preconfigured view does
not include information the user requires in a specific instance of care
|
3
|
|
TI11:
Recipient system identifies new or revised data
|
For existing patients, the recipient system will identify all discrete information
in the received document that is new or changed compared with the existing discrete
information in the receiving system
|
Identifying new or modified data automatically, enables clinicians to focus their
attention on relevant new and revised data resulting in more efficient patient care
following a patient's care transition. This also facilitates ease of data reconciliation
and prevention of duplicate testing and adverse patient events, thereby reducing health
care costs
|
3
|
Abbreviations: CPT, Current Procedural Terminology; EHR, electronic health records;
HIT, health information technology; ICD10, International Classification of Diseases,
Tenth Revision; LOINC, Logical Observation Identifiers Names and Codes; PAMI data,
problems, allergies, medications, and immunizations data; SNOMED, Systematized Nomenclature
of Medicine.
Table 2
Recommendations for clinical messaging
|
Priority 1
|
Required/Urgent/Now/Current-next version
|
|
Priority 2
|
Highly desired/Future priority/1–2 y/Subsequent version
|
|
Priority 3
|
Advanced/Future development
|
|
Clinical messaging
|
|
Feature/Function
|
Recommendation
|
Rationale
|
Priority
|
|
Outbound message functions
|
|
CO1:
Compose message
|
Sending user may create a patient-specific Direct message to send to a Direct recipient
|
Composing messages supports standard and familiar email-like functionality, allows
patient-specific information to be securely transferred from one HIT system to another
to support patient-specific care coordination
|
1
|
|
CO2:
Addresses message to a Direct recipient
|
Sending user may select a new recipient by selecting the recipient's name from a prepopulated
list or by entering his/her Direct address in the recipient field
|
This facilitates the end user's ability to send a Direct message to a Direct recipient
of their choosing, whether or not the system is preconfigured with the recipient's
Direct address
|
1
|
|
CO3:
Add attachments to patient-specific messages
|
Sending user may add one or more patient-specific attachments, to the outgoing patient-specific
message. Attachments will consistently be delivered with the message
Supported document types include structured data (e.g., any structured C-CDA document
type or a template with a combination of C-CDA sections, document types such as spreadsheets
(e.g., Excel), unstructured data (e.g., Word, PDF, and plain text files), and image
files (e.g., JPG and GIF)
|
The ability to add attachments allows robust communication in support of patient care
since it enables users to attach a variety of document types including scanned paper-based
documents and clinical images
|
1
|
|
CO4:
Forward messages within recipient organization
|
Recipient user can forward received messages and/or any associated attachments to
one or more other recipients within their organization as needed to support clinical
care
|
Forwarding messages supports team-based patient care by allowing appropriate sharing
of information
|
1
|
|
CO5:
Reply
|
Recipient user can reply to the sender of a Direct message, maintaining continuity
between the original received message and the reply
|
Reply functionality enables efficient Direct communication and maintains the continuity
of message strings
|
1
|
|
CO6:
Message Context
|
Sending and recipient users can identify the message Context. Context is established
based on a standard list of Context types. All automated Direct message templates
(see TO7) may have a preconfigured Context as part of the template specification.
Context may be determined from ADT fields, the document type, or other sources
|
A message Context that is visible and identifiable to the recipient helps to expedite
patient care. It also allows messages of specific Context types to be routed to the
appropriate user within the recipient's system
|
1
|
|
CO7:
Message Subject
|
Sending user can enter a message Subject as free text or selected from a predetermined
list of commonly used Subjects. The Subject specified by the sending user is displayed
to the receiving user(s)
|
This recommendation implements a standard and familiar email function and supports
efficient and/or automated sorting, routing, and management of messages based on the
Subject
|
2
|
|
CO8:
User-specific list of “favorite” Direct Recipients
|
Users can configure and maintain a list of their personal “favorite” or frequently
used Direct recipients
|
A favorites list facilitates the end user's ability to efficiently send a Direct message
to a Direct recipient by selecting the recipient from the sender's favorites list
|
2
|
|
CO9:
Multiple recipients
|
Users can send messages to multiple recipients simultaneously utilizing standard fields
of “To” and “CC” (carbon copy). There should be no “BCC” (blind carbon copy) functionality
|
The ability to send a message simultaneously to multiple recipients supports the inclusion
of additional relevant members of the care team into the TOC process. BCC functionality
is not appropriate for clinical messaging which may become a part of a patient's permanent
legal medical record
|
2
|
|
CO10:
Patient-specific distribution lists
|
Users can create, maintain, and utilize patient-specific message recipient distribution
lists and have the ability to easily select some or all members of a patient's lit
to receive a message
|
Patient-specific distribution lists allow for the maintenance of a list of a patient's
care team members. Such lists support the efficient routing of a single message to
more than one member of the patient's care team
|
2
|
|
CO11:
Send on behalf of
|
Sending user can compose and send a message on behalf of another individual with proper
authorization and attribution
|
This recommendation improves efficiency of communication for clinicians working within
a care team
|
2
|
|
CO12:
Message delivery notification
|
Sending user is notified if the message cannot be delivered to the intended recipient
or their designee. The system can be configured to notify the sending user of both
successful and failed delivery if the end user so desires. The failure notification
message includes a reason for failure if known
|
The sending user must have confidence that a sent message was delivered to the intended
recipient or their designee Unless users can confidently know that a message was delivered,
or was undeliverable, transition from existing messaging functionalities, such as
fax and postal mail, to Direct will be delayed A failed delivery notification may
be used by the sending organization as a trigger to initiate an investigation or troubleshooting
or to reconfigure their system or workflows to facilitate future communications
|
2
|
|
CO13:
Message Priority
|
Sending user can optionally indicate the Priority or level of importance of the message.
(i.e., urgent, standard, nonurgent). The specified Priority will be displayed to the
recipient. Organizations can configure that messages without a Priority indication
are sent as “standard”
|
The sending user will be able to indicate message urgency to recipient allowing the
recipient to prioritize which messages to attend to in what order. The level of importance
can also be used to trigger additional functionality such as sorting or routing of
messages
|
2
|
|
CO14:
Reply all
|
Recipient user can reply to the sender of a Direct message and to one or more additional
recipients of the original message
|
This replicates standard email functionality and facilitates inclusion of team members
on a response to a received message. This functionality is particularly valuable when
a patient is cared for by team members at multiple organizations
|
2
|
|
CO15:
Read receipt
|
Sending user can be notified once a sent message has been opened by the intended recipient
or their designee. The sending system can be configured to turn on/off read receipt
at the organization or individual level. System configuration can set up the appropriate
individual(s) or message pool(s) to receive read-receipt messages and the timeframe
to receive an “unopened message” notification. The sending organization can also configure
specific messages types that require read-receipt notification and/or allow the sender
to activate the read-receipt feature on the fly when sending a message. The read-receipt
message will also include the name and role of the individual in the recipient organization,
who opened the message
|
Read-receipt functionality ensures that the sender, or his/her designee, is informed
that a sent message has failed to reach a recipient, or if someone in the recipient
organization has actually opened the message in the period defined by the sender.
This feature assures timely follow-up and reduces the risk for clinical communications
and/or tasks to remain incomplete
|
3
|
|
CO16:
Configurable message receipt notification
|
Sending user can configure his/her message receipt notification to “yes” or “no” manually
or automatically based on the Priority of the outgoing message, and can configure
the timeframe for the notification. For example, urgent messages can be configured
to always trigger a failed message receipt within 8 hours of sending
|
Sending user will be aware of important message send failures alerting them of the
need to use alternative methods of communication, particularly in the event of urgent
message send failures
|
3
|
|
CO17:
Send pointers to large files maintained in the sending organization
|
Sending user is able to include in a message a URL/pointer to an image file (e.g.,
a scanned document or diagnostic image) maintained by the sending organization which
allows a message recipient to navigate to the stored image and view and download it
|
Diagnostic images and other large documents may not need to be sent as message attachments
in every case. Sending a pointer to the image/document allows the recipient the option
of viewing or downloading the document
|
3
|
|
CO18:
Prevent the forwarding of information specifically protected by HIPAA, 42 CFR Part
2, or other applicable statute
|
Sending user is able to:
1. Specify special privacy protections for the message including the specific statute
or other restriction applicable to the data/message
2. Specify that a specific message SHALL not be forwarded
3. Assert that consent has been received compliant with the requirements of 42 CFR
Part 2 or other restriction authorizing the sending of the message
The system can be configured at the organizational or user level to:
1. Display received information on special privacy protection to any recipient user.
An attempt to forward a message with specified special privacy protection results
in a warning to the user, who is alerted to the restriction and required to acknowledge
the warning prior to sending. The fact that the alert was presented and acknowledged
is logged by the system
2. Display received information on special privacy protection to any recipient user,
however, not permit forwarding of received messages specified as not to be forwarded
|
This recommendation prevents the distribution of patient information that would be
in violation of existing law or otherwise inappropriate
|
3
|
|
CO19:
Message forwarding outside of recipient organization
|
Recipient user can forward a received message and/or any associated attachments to
one or more recipients at a different organization or using a different HIT system.
Forwarding of specially protected information is prevented or limited (see CO18)
|
Forwarding of messages supports team-based care by sharing information when care team
members are in different organizations
|
3
|
|
Inbound message functions
|
|
CI1:
Automated patient identification
|
All EHRs, Health Information Service Providers (HISPs), and other HIT applications
receiving Direct messages automatically match incoming messages to the correct patient
for those already known within the recipient system. Only in the event that the patient
is new or cannot be automatically matched (e.g., a new referral to a specialist, or
patient demographics that might match more than one existing patient record), the
receiving system places the message in a work queue for manual matching or patient
registration
|
Patient matching must be automated to prevent impeding data flow to intended recipient(s)
and potentially creating an unsafe situation for the affected patient. With broad
adoption of Direct, timely care transitions and coordination require automatic matching.
Manual patient matching places an unsupportable burden on staff
|
1
|
|
CI2:
Message attachments
|
The receiving systems must allow the recipient to open and view a wide variety of
content types received as message attachments including structured data (C-CDA, or
a template with a combination of C-CDA sections, document types, Excel spreadsheets,
etc.); unstructured data (Word, PDF, plain text files, etc.) and images (JPG, GIF
files, DICOM, etc.). Patient-context information contained in the message attachment
should be visible or accessible to the clinical user
|
Receiving systems must not strip attachments from the message and must be able to
consume all supported attachment types. Included attachments were deemed necessary
for the optimal care of the patient by the sender and thus must be consumable. This
recommendation will increase the confidence that a sent attachment will be viewable
by the intended recipient
|
1
|
|
CI3:
Reliable recipient view
|
All clinically relevant message components and attachments (e.g., sender, intended
recipient, CCed recipients, message subject, message body text, message context, and
attachments) display reliably in a consistent manner to the receiving end user in
a personal in box. The content of standard documents (e.g., a document that conforms
to the C-CDA standard, or a template with a combination of C-CDA sections and/or document
types) are displayed to the user in a consistent format so that the user can become
familiar with the location of information in the document
|
The inbox as an access point for all data relating to the patient creates efficiency
and improves the chance that all the information will be reviewed. Consistent display
will familiarize the user with the format and allows for review that is more efficient
|
1
|
|
CI4:
Standardized use of discrete data
|
Standardized data vocabularies are included in a uniform fashion to support transmission
of discrete data. Minimum requirements are problems, allergies, medications, immunizations
(PAMI), and procedures
|
Standardized vocabulary creates care and documentation efficiencies and data integration
capabilities prevent transmission, interpretation, and data entry errors
|
1
|
|
CI5:
Recipient is able to view the sender's indicated message Priority
|
The recipient can view the message Priority indicated by the sender and can prioritize
his/her workflow based on this information
|
As clinicians frequently experience work force shortages and information overload,
this feature allows the recipient to prioritize his/her incoming messages
|
2
|
|
CI6:
Message sorting functions
|
The recipient user, or his/her delegate, is able to sort the list of received messages
by common characteristics, including date/time of receipt, patient, sending user,
recipient user, context, priority, or subject
|
This standard email functionality allows recipients to manage messages efficiently
|
2
|
|
CI7
Incoming message notification
|
Receiving systems provides the ability to configure, either at the organization or
individual level, real-time notifications to recipients regarding the receipt of a
Direct message (e.g., to a specified email or text messaging account). These notifications
do not include PHI
|
This functionality protects users from the need to constantly check their application
for new messages
|
2
|
|
CI8
Message routing based on Context
|
Receiving systems support configurable routing of messages based on Context metadata
(e.g., discharge, referral, care coordination, etc.) received with the message. This
routing includes the following functionalities:
1. The ability for a recipient to designate another individual or a work queue to
process some or all of their messages on his/her behalf
2. The ability to write message handling rules to enable auto processing (e.g., CC
or forward) of messages based on sender, context, patient, or subject to another individual
or to a work queue for processing
|
Auto-routing of messages based on message Context increases efficiency of care coordination,
supports team-based care, and decreases clutter in the provider's inbox, and increases
usability and adoption of Direct messaging
|
2
|
|
CI9:
Message forwarding to internal recipients without a Direct address
|
The recipient of a Direct message is able to forward the message and any attachments
to another user in of the same system in the same organization regardless of whether
the intended recipient is provisioned with a Direct address
|
Clinicians receiving clinical Direct messages may need to forward these messages to
others in their organization for processing even though these users may not be enabled
with the ability to send or receive external messages directly
|
2
|
Abbreviations: ADT fields, Admission, Discharge, Transfer fields; C-CDA, Consolidated
Clinical Document Architecture; HIPAA, Health Information Portability and Accountability
Act; HIT, health information technology; PHI, protected health information.
Table 3
Recommendations for administrative functions
|
Priority 1
|
Required/Urgent/Now/Current-next version
|
|
Priority 2
|
Highly desired/Future priority/1–2 y/Subsequent version
|
|
Priority 3
|
Advanced/Future development
|
|
Administration
|
|
Feature/Function
|
Recommendation
|
Rationale
|
Priority
|
|
Administrative functions
|
|
A1:
Any clinical User may have a Direct account
|
All clinical Users have full individual Direct messaging capability regardless of
whether they have a National Provider Identifier (NPI), e.g., care managers, nurses,
etc. may have their own Direct account
|
A provider directory service may require including the NPI when publishing the user's
Direct address. While intended to provide clarity between similarly named providers,
many health care providers do not have NPIs and would therefore be excluded from the
directory. Utilization of secure clinical messaging for care managers, care coordinators,
social workers, therapists, etc. is foundational for team-based care of patients
|
1
|
|
A2:
Locations and departments may have Direct accounts
|
Organizations have the capability to create departmental and location-based Direct
accounts to send and receive messages (e.g., messages intended for health information
management, admitting, the emergency department (ED), or other specific clinical departments)
in addition to accounts for ndividual clinicians
|
Utilization of secure messaging promotes patient care by involving clinicians and
other health care workers individually and based on departmental functions. For example,
a referral message could be routed to the referral staff, or a message regarding skilled
nursing placement to a case manager
|
1
|
|
A3:
Manual entry of Direct addresses
|
Users have the ability to enter the Direct address of an intended recipient manually
in addition to selecting a recipient from a directory. This functionality should be
provided only in conjunction with the requirement for a Failed Message Delivery/Receipt
Notification given the risk of errors with manual data entry
|
There are situations where users may need to send a Direct message to a recipient,
whose address is not available in their HIT system's directory. As patients and additional
members of their care team are provisioned with Direct addresses, this recommendation
becomes increasingly important. Processes must exist to assure that nonfunctional
or erroneous addresses are validated or otherwise trigger an alert to the sending
user or surrogate so that alternate means of communication can be utilized
|
2
|
|
A4:
Request patient-specific documents
|
A standard automated methodology exists to allow a Direct user to request a standard
C-CDA document and/or a template with a combination of C-CDA document types or sections
from another Direct user. The system allows the sender/requestor to specify the specific
document(s) requested (e.g., a patient summary/Continuity of Care Document [CCD],
discharge summary, or encounter summary), the modality to send the response (e.g.,
Direct message vs. fax), and where the document(s) should be sent (e.g., to a Direct
address or fax number)
|
While Direct is utilized primarily to push messages, it can also be used to mimic
some of the functionality of query-based, or “pull,” document exchange. Users can
send a message that requests a recipient system to automatically send patient information
to the requestor. For a patient in the ED, for example, the local HIT system could
manually or automatically query the EHR of the patient's primary care physician or
other treating provider for information and receive an automated response with a patient
summary CCD to facilitate safer, timelier, more efficient, and cost-effective care
|
2
|
|
A5:
Customizable request for information
|
User can send a Direct message to request specific information from the recipient
using a configurable multiselect pick list to indicate the information requested
|
This recommendation facilitates receiving the specific information needed to most
efficiently and effectively care for the patient. It can avoid the inclusion of unnecessary
information, limiting the time and effort required to locate pertinent data
|
3
|
|
A6:
Automatic forwarding when the addressee is unable to receive messages
|
When a user sends a message and the recipient is unable to receive the message, it
will be auto-forwarded to a designated user and/or pool
|
A sender may not know if the intended recipient of a message is out of the office,
covered by another provider, having outside messages routinely routed to another user
or pool, or has left the organization. Automated forwarding of the message to an assigned
back-up recipient/provider, who will assume care of the patient, or to a pool that
manages undeliverable messages will ensure that important patient-related messages
are not lost
|
3
|
|
A7:
Nonpatient-specific administrative messages and attachments
|
Sending user can add one or more attachments to an outgoing non-patient-specific message.
Attachments will consistently be delivered with the message.
Supported document types include documents that contain reports and information that
may apply to multiple patients or no patients and include, but are not limited to,
spreadsheets, PDF, and Word documents
|
The ability to utilize Direct messaging to support the secure transmission of non-patient-specific
messages and attachments supports communication which is required as a part of health
care organizations' administrative functions including quality improvement, insurance
preauthorization, and other billing and reporting functions
|
3
|
Abbreviations: EHR, electronic health records; HIT, health information technology.
Table 4
Categorization of recommended features/functions
|
Feature/Function
|
Priority 1
|
Priority 2
|
Priority 3
|
Total
|
|
Transitions of care
|
Outbound message functions
|
5
|
4
|
2
|
11
|
|
Inbound message functions
|
6
|
2
|
3
|
11
|
|
Clinical messaging
|
Outbound message functions
|
6
|
8
|
5
|
19
|
|
Inbound message functions
|
4
|
5
|
0
|
9
|
|
Administrative functions
|
|
2
|
2
|
3
|
7
|
|
Total
|
|
23
|
21
|
13
|
57
|
The largest number (23) of recommended features and functions is prioritized as priority
1, or highest need, reflecting clinicians' urgent desire for basic messaging functionality
to safely and efficiently utilize Direct messaging to support clinical care. These
functionalities should be the primary focus of HIT vendors for current development
to assure that all applications satisfy these basic requirements. The 21 features
categorized as priority 2 are highly desired by clinicians and should be included
in near term development for delivery and implementation ideally in the next 1 to
2 years. The 13 functions designated as priority 3 include those that clinicians,
HIT vendors, and other stakeholders believe will require more development, collaboration,
and consensus building among clinicians, vendors, and other groups, and/or the further
development of technology standards ([Table 4]).
Some recommended functions apply to multiple use cases, e.g., transitions of care
and clinical messaging, but are listed only once in the tables to avoid redundancy.
Similar functions are listed more than once when associated with use case-specific
recommendations or rationale. It is the intention of the authors that these recommendations
be addressed by HIT vendors and policy makers as a whole, based on the priorities
specified, rather than independently addressing the requirements for specific functions.
Discussion
These recommendations focus on communication between clinicians. Direct interoperability
is and will be used across a wide variety of situations, systems, and groups. While
other uses (e.g., Direct messaging between clinicians and patients) will also benefit
from the implementation of the recommended features and functions, vendors and users
should realize that additional requirements will likely be necessary in the future
to address the unique needs of additional use cases.
Some EHR and HIT vendors have already developed many of the recommended features and
functions. Some of the advanced functions recommended will require not only the development
of a new software by vendors, but also the evolution of the Direct Standard itself.
An example of this is the development of an Implementation Guide for Expressing Context
in Direct Messaging.[13]
While the focus of this consensus statement is Direct interoperability, many recommendations
also apply to other methods of secure clinical information exchange including query-based
document exchange and interoperability using application-programming interfaces (APIs).
The recommendations address issues of both message content/payload and transport,
providing input and perspective from the viewpoint of clinicians who desire to utilize
these interoperability methodologies to support the care of individuals and populations.
Conclusion
We recommend that the vendor community utilize this list of desired features and functions
to ensure that the highest priority items are available to end users of Direct interoperability
in the shortest possible timeframe, followed by the next highest priority group of
features and functions. We further encourage policy makers to consider this list of
clinically desirable functionality when establishing policies and regulations to support
the interoperability of health information.
Clinical Relevance Statement
Automated, real-time sending and receipt of secure clinical messages and attachments
via Direct interoperability by members of a patient's care team helps make them aware
of care transitions and provides them with current clinical information. This enhances
their ability to safely, efficiently, and effectively care for patients. Electronic
sharing of clinical information across disparate organizations, EHRs, and other HIT
systems can help to overcome barriers created by the patient's care teams' separate
EHR systems and enables the creation and management of a shared patient care plan.
Timely receipt of messages enhances the safety and efficiency of patient care by facilitating
information reconciliation in the recipient systems and appropriate patient outreach
to ensure patient understanding of the updated plan of care. It also helps prevent
unnecessary duplicate testing and adverse events.
Multiple Choice Questions
-
EHR interoperability utilizing the Direct Protocol is currently:
-
Available in all Meaningful Use certified EHR systems
-
Being tested in some EHR systems
-
Is untested and is in development within the public/private sector
Correct Answer: The correct answer is option a. Direct interoperable capability has been required
to be available in all Certified Electronic Health Record Technology (CEHRT) systems
since the 2014 edition of certification.
-
The use of structured vocabularies for problems, allergies, medications, immunizations,
and procedures allows for:
-
Enhanced patient understanding of these elements
-
EHR documentation of these elements as discrete data
-
The ability for a Direct message recipient HIT system to consume these data elements
discretely
-
b and c
Correct Answer: The correct answer is option d. The use of structured vocabularies for problems,
allergies, medications, immunizations (called PAMI Data), and procedures allows HIT
system end users to enter patient data as “discrete” or computable data. When these
data are structured using a standard vocabulary, it allows an EHR or other HIT system
receiving a Direct message containing discrete data to consume the data, thereby avoiding
transcription errors and facilitating the use of received information for analytics,
decision support, reporting, and other purposes. The use of structured vocabularies
is unrelated to patient understanding of their clinical information.
-
Optimal use of Direct interoperability requires
Correct Answer: The correct answer is option d. Like any other software implementation, optimal use
of Direct interoperability requires configuration, consideration of role-based workflows
within the organization, and end user training and support. The best implementation
of Direct interoperability might also include considerations of role-based workflows
across organizations where messages will be sent and received.
Conflict of Interest
None.
Acknowledgments
The authors are grateful for the workgroup support of Kelly Gwynn, Natasha Kreisle,
and DirectTrust; for the contributions of the workgroup members that are not listed
as authors: David Camitta, MD, MS – Dignity Health, Margaret Donahue, MD – Veterans
Affairs, Lucy Johns, MPH – DirectTrust, Francisco Rhein, MD – Dignity Health, and
Steven Waldren, MD, MS – American Academy of Family Physicians; for the extensive
comments and feedback provided by our clinical and information technology colleagues
in response to the draft recommendations; and the Office of the National Coordinator
for Health Information Technology, which provided a forum for the public presentation
and discussion of the recommendations.
Protection of Human and Animal Subjects
This manuscript does not involve any research on human subjects.
-
References
- 1 There are numerous sources of information about the Direct Standard and the Direct
Project. The Direct Project maintains a wiki at http://wiki.directproject.org/ . A comprehensive overview of the Direct Project is The Direct Project Overview from
February, 2010, available at: http://wiki.directproject.org/file/view/DirectProjectOverview.pdf . Accessed March 01, 2018 . The technical protocols and specifications for Direct
are specified in the Applicability Statement for Secure Health Transport of the Direct
Project, available at: http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport . Accessed March 01, 2018
- 2 HITECH Act Enforcement Interim Final Rule. Available at: https://www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/index.html . Accessed March 01, 2018
- 3 DirectTrust Reports Steady Growth in Number of Direct Exchange Users. Addresses
and Transactions during Third Quarter; October 24, 2017. Available at: http://www.globenewswire.com/news-release/2017/10/24/1152458/0/en/DirectTrust-Reports-Steady-Growth-in-Number-of-Direct-Exchange-Users-Addresses-and-Transactions-during-Third-Quarter.html . Accessed March 01, 2018
- 4 RI healthcare providers reach direct messaging milestone. R I Med J (2013) 2014;
97 (04) 48
- 5
Isetts B.
Integrating MTM (MTM) services provided by community pharmacists into a community-based
Accountable Care Organization (ACO). Pharmacy 2017; 5 (04) 56
- 6
Reicher JJ,
Reicher MA.
Implementation of certified EHR, patient portal, and “Direct” messaging technology
in a radiology environment enhances communication of radiology results to both referring
physicians and patients. J Digit Imaging 2016; 29 (03) 337-340
- 7
Sujansky W,
Wilson T.
DIRECT secure messaging as a common transport layer for reporting structured and unstructured
lab results to outpatient providers. J Biomed Inform 2015; 54: 191-201
- 8
Terry K.
How to get started with Direct messaging. Many physicians don't use or are unaware
of Direct secure messaging, but it can help improve care coordination--provided you
can navigate its challenges. Med Econ 2015; 92 (07) 42-46
- 9
Walker DM.
Does participation in health information exchange improve hospital efficiency?. Health
Care Manage Sci 2017;
- 10
Lehmann CU,
Kressly S,
Hart WWC,
Johnson KB,
Frisse ME.
Barriers to pediatric health information exchange. Pediatrics 2017; 139 (05) e20162653
- 11 DirectTrust is a collaborative non-profit association of health IT and health care
provider organizations to support secure, interoperable health information exchange
via Direct interoperability and other electronic protocols. Available at: https://www.directtrust.org/about-directtrust/ . Accessed March 01, 2018
- 12 DirectTrust Clinicians' Steering Group for Direct Interoperability in Care Transitions
and Coordination. White Paper: Feature and Function Recommendations to the HIT Industry
to Optimize Clinician Usability of Direct Interoperability to Enhance Patient Care.
Available at: https://www.directtrust.org/wp-content/uploads/2017/03/WhitePaper_Final_03.16.2017.pdf . Accessed March 01, 2018
- 13 The Direct Project. Implementation Guide for Expressing Context in Direct Messaging.
Available at: http://wiki.directproject.org/file/view/Implementation+Guide+for+Expressing+Context+in+Direct+Messaging+v1.0-DRAFT-2016122901.docx/602899718/Implementation%20Guide%20for%20Expressing%20Context%20in%20Direct%20Messaging%20v1.0-DRAFT-2016122901.docx . Accessed July 27, 2018
Address for correspondence
Steven R. Lane, MD, MPH
Sutter Health, Palo Alto Medical Foundation
795 El Camino Real, Palo Alto, CA 94301
United States
Download PDF
