Transitions+of+Care+Direct+Profile+-+Proposed

=Introduction to the Transitions of Care Direct Profile=

This profile is designed to serve the needs of implementers who may wish to use the Direct protocol as a transport method for the four key information exchanges associated with the S&I Framework Transitions of Care Initiative. The approach used by the Transitions of Care Initiative was to reuse existing standards wherever possible, and in this initiative, CDA was chosen as the preferred platform to exchange clinical documentation. However, the guidance from the initiative as of yet does not define or recommend a transport method to be used by implementers. Also, privacy and security requirements have not been provided to implementers to be applied to the implementation environment.

The main purpose of this is to provide non-prescriptive, informative guidance to implementers to meet that need. The profile represents the collective efforts of Transitions of Care Initiative and will be updated through subsequent versions to support on-the-ground feedback from pilot implementations and vendors who implement the information exchanges outlined through the Transitions of Care Initiative.

This specific profile also provides a further level of constrained configuration choices where necessary in use of both CDA and the Direct protocols to ensure that they can be used in their respective domains in an integrated manner between different actors. The profile lays out an implementation path for those implementers who wish to exchange the Transition of Care clinical documents without being overly constraining in specifying transport, privacy, or security specifics, to allow for customization and optimization in support of specific environments. The deployment models outlined in the S&I Framework Transitions of Care Initiative should be reused wherever possible, and this profile further expands in more detail on how these deployment models can directly apply to implementation environments.

Structure of the Profile
The profile establishes an implicit framework of actors, roles, and transactions that will need to be supported for a care transition information exchange. Transactions are identified within this profile that will need to be implemented in order to use the Direct protocol (SMTP-based or XDR) as a transport mechanism for a care transition. Many of these transactions relate to the interaction of the actors and roles within a care transition with the HISP, which serves as its own actor with its own set of roles. The profile also outlines specific information exchange flows that this profile would support, as well as security requirements associated with each of these flows. =Profile Use Case= The use cases applicable to this profile are drawn from the S&I Framework Transitions of Care Use Case. Specifically, this profile supports the following user stories:
 * **Exchange of Discharge Summary to Support the Transfer of Patient Information from One Provider to another Provider **
 * **Exchange of Clinical Summaries to Support the Closed Loop Referral of a Patient from One Provider to Another **
 * **Exchange of Information to Support the Transfer of Patient Information from a One Provider to Another **
 * **Exchange of Clinical Summaries to Support the Closed Loop Referral of a Patient from a One Provider to Another **

//**Addition needed: mapping of use case roles to information exchange participants**//

Profile Actors and Roles
The actors used in this profile are drawn from existing actors already defined in the S&I Framework Transitions of Care Use Case. The technical roles applied in this profile would be specific to the Electronic Health Record (EHR) System and to the HISP that are outlined in the Use Case. The following table outlines the actors and expected roles for those actors in this profile at a high-level: (EHR) System || Information Source Information Receiver || Technical || HISP Services are defined in the next section and this role encapsulates a broad set of potential services that could be provided by a HISP. =Services orchestration= This profile assumes a set of services are made available from the HISP to support the needs of Direct participants. These services are needed to support the exchange and are up to the HISP to specifically develop and define, as per the Direct Rules of the Road applicability statements. In the context of this profile, these services are defined at a high level and make the assumption that the HISP will implement them according to the Direct specifications. Within the profile, the services are described in the role titled "//**HISP Services**//". A summary of the HISP services is below:
 * **Actor Name** || **Potential Roles** || **Type of Actor** ||
 * Provider ||  || Business ||
 * Electronic Health Record
 * HISP || HISP Services || Technical ||
 * Specialist ||  || Business ||
 * Authorization Service - The HISP will need to support the authorization of providers and their EHR's to send a secure message using the HISP infrastructure
 * Authentication Service - The HISP will need to support the authentication of a specific individual to send and receive information associated with a care transition
 * Consent Service - The HISP will need to support the management of consent associated with a care transition

In addition, a HISP may need to define new services that need to be provided through the HISP and orchestrated with Direct participants to support the requirements of Direct participants. This profile may identify these new services that the HISP should provide as //**extensions**// to the profile, in support of specific scenarios. An example of an extension would be a HISP providing services to support quality reporting requirements.

Transaction Orchestration
A set of transactions are defined within this profile to provide a description of each transaction in detail, specifying the standards used, the information transferred, and the conditions under which the transaction is required or optional.

The following transactions are needed in support of this profile, and include internal EHR functions and activities associated with the generation of specific content for exchange: exchange within the EHR system || This is an internal EHR function || exchange to a secure message || This is an internal EHR function || based message (using SMTP or IHE XDR) || Authenticate Provider EHR System Authorize Provider Obtain Patient Consent || discharge summary document ||  || discharge instructions document ||  || consultation summary document ||  || including Clinical Summary || The workflow needed to generate the consultation request information and the clinical summary document ||  || An additional set of transactions are available that are being further defined: send a secure message ||  || to the S/MIME "boundary." ||  || identify of the provider (will also include verification of patient where appropriate) ||   || S/MIME "boundary". ||  || digital certificate for a specific provider ||   || =Information Exchanges= This section outlines each of the information exchanges that the Direct profile can support. The guidance in this profile is intended to apply solely to these information exchanges, and while future work may allow for this profile to be expanded in support of other information exchanges for care transitions, the intention is that this profile supports only those key information exchanges defined in the S&I Framework Transitions of Care Use Case and in the harmonization of standards through the S&I Framework.
 * **Transaction Name** || **Description of Transaction** || **Prerequisites** ||
 * Assemble CDA Document || Used to assemble the specific information
 * Attach CDA Document || Used to attach the specific information
 * Send Secure Message || The process to send a secure Direct-protocol
 * Generate Discharge Summary || The workflow needed to generate the
 * Generate Discharge Instructions || The workflow needed to generate the
 * Generate Consultation Summary || The workflow needed to generate the
 * Generate Consultation Request
 * **Transaction Name** || **Description of Transaction** || **Prerequisites** ||
 * Send Provider Directory Query || Used to locate a provider or specialist to
 * Authenticate Provider EHR System || Authentication mechanism utilized up
 * Authorize Provider || Authorization mechanism that verifies the
 * Obtain Patient Consent || Consent mechanism utilized up to the
 * Query Certificate Directory || Query mechanism used to query for a

Constraints for Exchanges
This profile specifically does not specify at this time any profile-level constraints, such as transport, privacy, or security constraints. There are several reasons for this: The four information exchanges that this profile supports (and the specific system actors associated with each of these key information exchanges) are shown below:
 * Constraints for transport, security, and privacy are inherited from the Direct specification and should be used to form the foundational level of constraints for information exchange.
 * Constraints for the information exchanges (content) are inherited from the Transitions of Care Implementation Guidance, and from the underlying CDA standard.
 * Additional constraints can be defined by an implementer or vendor depending on the unique conditions of their implementation environment. Not all constraints can be captured in this profile.

Discharge Summary
The Discharge Summary is the clinical document used in the event that a patient is discharged from a healthcare provider, containing an overview of patient care information, such as demographic information, active reconciled medication list (with doses and sig), allergy list, problem list, and reason for admission. The document includes both a standard dataset and a discharge context relevant dataset, both of which are determined by the discharging provider organization in accordance with local policy, regulations and law. At discharge, the summary might include content for the Discharge Instruction as well as Discharge Summary.
 * **Sender:** EHR System (Hospital)
 * **Receiver:** EHR System (Primary Care Physician)

Discharge Instructions
The Discharge Instructions contains the dataset relevant to the Discharge Summary context, which includes follow up/plan of care. The Discharge Instructions may be generic, patient specific, or disease specific depending upon the facility’s practices and the patient’s needs. The document includes data relevant to the following sections: Plan of care, allergies/adverse reactions/alerts, problems list, hospital discharge medications, advance directions, immunizations, and medical equipment. The document is given to the patient by their nurse or care manager at or a short time before physical discharge and a copy is sent to the patient’s PCP or Care Team. The patient’s acknowledgement that they have received, understood, and agreed to follow the Discharge Instructions, triggers the actual physical discharge.
 * **Sender:** EHR System (Hospital)
 * **Receiver:** EHR System (Primary Care Physician)

Consultation Summary
The Consultation Summary is the document that contains information determined by the provider organization surrounding a consultation and consultation context-relevant data. When the PCP physician determines that the patient needs to be referred to a specialist, they prepare the Consultation Request within the EHR. It is addressed to the appropriate specialist, who in accordance with practice policies and workflow, reviews the document and orders any additional tests to be performed for the patient prior to the office visit. The Consultation summary should always include a basic set of information on the consultation that might also include content for the Clinical Instruction as well as the Consultation Summary. Consultation summary content examples include demographic information, active reconciled medication list (with doses and sig), allergy list, problem list and variable data relevant to the context of the request.
 * **Sender:** EHR System (Primary Care Physician)
 * **Receiver:** EHR System (Specialist)

Consultation Request Including Clinical Summary
This information exchange would contain a standard set of data surrounding a consultation, and consultation context-relevant data, which is determined by the provider organization in accordance with local policy, regulations and law. The receiving provider through its EHR system may determine how to incorporate and present the Consultation Summary document. The Clinical Summary is an after-visit summary document that may contain variable data relevant to the context of the request. In addition, this information exchange also includes a PCP-selected referral-specific variable dataset. It can include any of the following items: Patient name, provider’s office contact information, date and location of visit, an updated medication list, updated vitals, reason(s) for visit, procedures and other instructions based on clinical discussions that took place during the office visit, any updates to a problem list, immunizations or medications administered during visit, summary of topics covered/considered during visit, time and location of next appointment/testing if scheduled, or a recommended appointment time if not scheduled, list of other appointments and tests that the patient needs to schedule with contact information, recommended patient decision aids, laboratory and other diagnostic test orders, test/laboratory results (if received before 24 hours after visit), and symptoms. The Clinical Summary is addressed and sent to the PCP’s EHR as well as the patient’s PHR. =Information Exchange Flows= This section captures the information exchange flows, including orchestration of the transactions needed to support the exchange of information using Direct. This is the basis for the profile and shows the interaction and orchestration of the transactions, roles, and actors defined within this profile.
 * **Sender:** EHR System (Hospital)
 * **Receivers:** EHR System (Primary Care Physician) AND/OR PHR System (Personal Health Record)

Base Flow - Provider to Provider
The following scenario describes a normal information exchange flow using Direct to send a secure email message to another provider. This diagram outlines the exchange of a discharge summary to support the transfer of patient information from one provider to another provider, with the transfer of information occurring through a secure email message.



The following scenario outlines the use of Direct to send a secure message using IHE XDR:

Base Flow - Provider to Specialist
=Alternative Information Exchange Flows= Additional scenarios that this profile is intended to support includes the following flows: = = =Policy requirements= To be aligned with the policies outlined in the TOC Policy and Service Analysis =Trust model= This section lays out specific trust and security requirements for this profile between the exchange participants, and aligns that specifically to the Direct Trust Model. The intention of this profile is to inherit directly from the Direct Trust Model in all cases. Specific trust and security requirements for this profile are as follows:
 * Beacon Community - Providing Information to a Disease Registry using Direct
 * State HIE - TBD
 * LTPAC - TBD
 * 1) A security profile is in place for the HISP on its "edge" boundaries
 * There is an authentication mechanism utilized up to the S/MIME "boundary."
 * There is a consent mechanism in place to capture patient consent prior to each care transition and also to process patient consent directives where applicable.
 * For each care transition, the data at rest is encrypted using applicable standards.
 * 1) There needs to be a specific certificate discovery mechanism in place to allow for the discovery of digital certificates for providers/specialists who are on the receiving end of a care transition
 * 2) There needs to be a certificate directory mechanism within the HISP
 * 3) Authorization mechanism will need to be in place (noted in the Direct Trust Model as identity verification)

Additional conditions of trust can be defined by implementers directly. //**(further TBD)**//

=Additional Supporting Guidance=

TBD