PDF icon Download PDF
Open Access
CC-BY-NC-ND 4.0 · Appl Clin Inform 2018; 09(01): 205-220
DOI: 10.1055/s-0038-1637007
State of the Art/Best Practice Paper
Schattauer GmbH Stuttgart

Consensus Statement: Feature and Function Recommendations to Optimize Clinician Usability of Direct Interoperability to Enhance Patient Care

Steven R. Lane
1   Department of Family Medicine, Sutter Health, Palo Alto Medical Foundation, Palo Alto, California, United States
,
Holly Miller
2   MedAllies, Fishkill, New York, United States
,
Elizabeth Ames
3   Information Technology, Sutter Health, Mather, California, United States
,
Lawrence Garber
4   Department of Internal Medicine, Reliant Medical Group, Worcester, Massachusetts, United States
,
David C. Kibbe
5   DirectTrust, Washington, District of Columbia, United States
,
Joseph H. Schneider
6   Department of Pediatrics, University of Texas Southwestern, Dallas, Texas, United States
,
Christoph U. Lehmann
7   Biomedical Informatics, Vanderbilt University Medical Center, Nashville, Tennessee, United States
,
DirectTrust Clinicians' Steering Group› Author Affiliations
Further Information

Address for correspondence

Steven R. Lane, MD, MPH
Sutter Health, Palo Alto Medical Foundation
795 El Camino Real, Palo Alto, CA 94301
United States   

Publication History

26 September 2017

21 January 2018

Publication Date:
21 March 2018 (online)

Also available ateRef
 
 PDF Download Permissions and Reprints

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

  1. 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.

  2. 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.

  3. Optimal use of Direct interoperability requires

    • EHR configuration

    • Consideration of role-based workflows prior to implementation

    • End user training and support

    • All of the above

    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.



Address for correspondence

Steven R. Lane, MD, MPH
Sutter Health, Palo Alto Medical Foundation
795 El Camino Real, Palo Alto, CA 94301
United States   


  Permissions and Reprints