ToC+Architecture+Overview+and+Implications

include component="page" wikiName="siframework" page="TOC Header" This is the wiki page to discuss and document the Architecture Overview and Implications for the Transition of Care (ToC) Use Cases as defined by the Transition of Care S&I Framework Discovery Phase Use Case development completed March 2011.

=﻿Overview=

The Transition Of Care Use Cases describe the sample user stories that are executed when a patient is being transferred from one care setting to another care setting or home. In addition, the Use Cases also identify the content that needs to be exchanged for the Transition of Care to happen seamlessly using electronic health information (See Section 9.0 of the Final ToC Use Case). The goal of the Architecture and Implementation Requirements SWG is to take the Use Cases and delve down into an architecture which can support the ToC Use Cases as well as delineating the implementation requirements required for each component within the system.

=Overview of the Information Flow and the System Interactions=

The following diagram is an abstract model of the interchange that helps visualize the information flow and the systems that are involved in the care transitions:

As shown in the diagram, the ToC user stories identify a "Sender", "Receiver", "Sending ToC System", "Receiving ToC System" which are minimally required for the user stories to be met. Senders and Receivers can be Providers, PCP's, Specialists, Patients etc. The Sending and Receiving ToC Systems can be EMR's, EHR's, Clinical Portals, other types of clinical systems used by care providers, PHR's etc. The Information that is exchanged between the Sending and the Receiving System can be one of the four different types of ToC Information Packages identified above. The core data elements that will be exchanged as part of each of the four different ToC Information Packages will be identified and defined by the Clinical Information Model SWG.

=Overview of the System Architecture=

In order to implement the ToC user stories in the real world, organizations need to understand the major components making up the sending and receiving systems. At the application level, Information Source and Information Consumer Enterprises need to be able to create/receive and view the clinical content associated with the ToC. Additionally,the Information Consumer Enterprise needs to be able to incorporate relevant Transition of Care information into its system. Just as important is the existence of the System infrastructure which provides such functionality as the Security and Privacy, and the transport of the clinical information from one Enterprise to another. The diagram below is a pictorial representation of the System components which need to exist in real world implementations.

Together these major components provide critical capabilities which allow the system to deliver the required functionality for real world implementations. This includes:


 * 1) **Sender's ToC and Receiver's ToC System Capabilities**//:// What kind of capabilities need to exist minimally in a Sending or Receiving ToC System ?
 * 2) **Core Data Elements** : What are the exact data elements that need to be included in the ToC Information Packages ?
 * 3) **Standards**: What are the candidate standards that can be used for each of the above areas ?
 * 4) **Transport**: How will information be transferred between the sending and the receiving system ?
 * 5) **Security and Privacy**: What kind of security and privacy practices need to in place to protect PHI ?
 * 6) **Addressing**: How will senders, receivers, patients be identified ?
 * 7) **Patient Consent**: What kind of patient consents are required for the ToC user stories to be implemented ?
 * 8) **Patient Correlation across enterprises**: When the Transition is across enterprises what kind of correlation needs to happen ?

The following section gives a short overview of the capabilities required to meet the needs of the ToC, including in some cases implementation mechanisms that might be deployed. Since the current S&I Framework ToC Initiative focuses primarily on the application level, this phase of the development will be focused on items #1 (Sender's and Receiver's ToC System Capabilities), #2 (Core Data Elements) and #3 (Standards). In other words the ToC Initiative will be creating recommendations in terms of standards, services and policies that are related to item1 #1, #2 and #3..

Sending and Receiving System Capabilities (ToC)
The capabilities that are essential for effectively exchanging electronic health information are shown in the ToC System Component Overview Diagram above as part of the "Sender's and Receiver's ToC Systems". For the purpose of the ToC user stories, the only capabilities that will be covered will be the creating, receiving and viewing of the clinical information; as well as the incorporation of ToC Information into Receiver's ToC Systems as it relates to the ToC initiative. The focus of the Architecture and Implementation RQ SWG will be to refine the architecture and implementation requirements related to the sending and receiving capabilities.

Core Data Elements (ToC)
The core data elements that are required for the ToC Initiative will be identified and further refined as part of the Clinical Information Model SWG and the results will be incorporated into the capabilities identified above.

Standards Selected: (ToC)
The standards that will be selected to best implement the ToC core data elements will be chosen based on the analysis of the Standards Analysis SWG. The candidates for implementing the core data elements are:
 * C32 / CCD based specification.
 * CCR based specification.
 * GreenCDA based specification.

The standards for implementing other areas such as the Transport, Security and Privacy, Patient Correlation, Patient Consent etc.. are not part of the ToC Initiative, but a brief discussion of these capabilities is included as informative content.

Transport
Transport in the above context defines the mechanisms that can be used to transfer the content electronically between the Sending and the Receiving Systems. For ToC Transport an organization can choose to implement mechanisms based on Direct specifications, IHE TF profiles, NHIN Exchange specifications etc. For the purpose of this initiative it is assumed that one of the above or equivalent mechanisms are being used to transfer content between the Sending and the Receiving Systems.

Security and Privacy
To ensure PHI is not disclosed inappropriately, the initiative assumes that organizations are adhering to HIPAA privacy policies and have security practices that protect the patient's information for all information exchanges. The organizations security and privacy practices when coupled with the appropriate Transport can ensure that PHI is protected from the Sender to the Receiver through all the intermediary systems involved. In addition the Auditing and other security controls that an organization has in place should be able to meet the required MU, HIPAA and NIST regulations.

Addressing
The addressing here refers to the activity of identifying the senders and receivers of ToC information. The addressing can be implemented based on Direct specifications, IHE TF profiles, NHIN Exchange specifications etc. For the purpose of this initiative it is assumed that one of the above or equivalent mechanisms are being used to identify senders and receivers and no new mechanisms are developed as part of this initiative.

Patient Consent
Organizations are assumed to have patient consent policies in place as appropriate and these existing mechanisms will be used by the senders and receivers before ToC information is exchanged between the senders and the receivers.

Patient Correlation across Enterprises
ToC Initiative does not require Patient correlation to exist in order for information to be exchanged between the enterprises for ToC user stories. However, Organizations can leverage any pre-existing mechanisms for correlating patients across enterprises such as the use of XCPD based standards, NHIN Exchange specifications.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"