ToC+-+Final+Use+Case

include component="page" wikiName="siframework" page="TOC Header" toc


 * Thank you all for your participation. At this point the content has been finalized for the Elements in Transition of Care Use Case and below you can find links to the Final versions of the Use Case Narrative as well as the Functional Requirements Spreadsheet i.e. the Use Case Package. The documents below reflect updates that were proposed and agreed upon during the formal Consensus Process. Please contact the Use Case and Requirements Support Leads if you have any remaining questions or concerns.**

**To download the Microsoft Excel version of the Final Functional Requirements spreadsheet, please click [|here].** **To download the Microsoft Excel version of the Final Functional Requirements spreadsheet, with Amendments please click [|here].** **To download the Microsoft Word version of the Final Transition of Care Use Case, please click [|here.]**

**1.0 Preface and Introduction**
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange; maximize efficiency, encourage rapid learning, and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including; patients, their significant others and family members, providers, vendors, standards organizations, public health organizations, and Federal agencies.

These Use Cases describe:
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data required in the data exchange

The Use Case is the foundation for identifying and specifying the standards required to support the data exchange and developing reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards.

2.0 Overview and Scope
The Initiative, Elements in Transition of Care, defines the electronic communication and data elements necessary for clinical information exchange to support transfers of care between providers and to inform patients.

This Use Case addresses multiple scenarios. The first scenario focuses on the exchange of patient information between providers to accomplish a successful transition in care from one care environment to another. This includes transitions between acute, long-term care, nursing facility, rehabilitation, home healthcare, as well as discharges to home with follow up by primary care or specialty care provider(s). Transitions within the same care setting are not included in the scope of this Initiative. The Use Case includes referrals for the purpose of consultations.

The second scenario focuses on the sharing of electronic clinical information from providers to their patients, including the data interchange required to support the needs of a patient -during these transitions of care. In this scenario, the patient has the ability to access and incorporate their available clinical information into their PHR. For both scenarios, it is important to have common transport standards for the secure and interoperable exchange of electronic health information in the context of Elements in Transition of Care.

Successful outcomes and metrics of this Use Case include: [This needs to be updated, once the Success Metrics Committee has completed their work – HM]
 * 1) The number of providers sharing Transitions of Care summaries
 * 2) The number of organizations who have been certified to produce valid specifications (Software development/Tools organizations)
 * 3) The time reduction for creation of new minimal unstructured summaries and structured summaries
 * 4) Cost reduction for creation of core elements within Transitions of Care
 * 5) Improvement in ability to achieve MU criteria
 * 6) Process improvement efforts related to transfer patterns in a health information technology environment
 * 7) Enhanced patient clinical outcomes secondary to self-awareness and involvement in their care
 * 8) Identifying best practice IT standards to promote the interoperability of systems to successfully exchange clinical information safely and securely and to enable the recipient to view the clinical information in a human readable format.

2.1 In Scope

 * Clinical Summary information and its basic dataset(s) for the Transition of Care to include the transfer of care and the exchange of clinical information between providers and between providers and patients
 * While all transitions between different care settings as discussed in the overview are to be supported over the longer term, the initial scope is focused on transitions necessary to support transitions from eligible providers, hospitals and critical access hospitals as defined in Meaningful Use rules for Stage 1. Additionally, the Use Case will give secondary priority to transition recommendations for Stage 2 Meaningful Use. The resulting requirements should provide a base for future support of additional transitions from other providers and organizations. It is noted that in order to best support care transitions there is a real need to include nurses and other non-physician clinicians, and consideration will be given to include these professionals as expeditiously as possible.

2.2 Out of Scope

 * The comprehensive EHR
 * Financial Information, except for basic insurance information, will not be sent
 * While Query Transactions are out of scope, consideration of metadata necessary to tag clinical summaries to support queries is within scope.
 * Sharing of clinical summaries for other purposes; e.g., claims submission
 * Transmission protocols are out of scope since the providers would not need to address the transport, though the system itself (outside the scope of a use case) would have to address the most efficient means of transport from sender to receiver.
 * Defining or modifying existing clinical medicine practices

2.3 Background
The Transition of Care Initiative is key to healthcare reform because its implementation will contribute to the overall cost savings within the US health system through enhanced care coordination, improved clinical outcomes and care efficiency, and decreased adverse events. Therefore this Transition of Care Initiative is aligned closely with the goals of Meaningful Use Stage 1 and anticipated Stage 2 as well as addressing various Prioritization Criteria as described next. Furthermore, the Transition of Care Initiative supports various evidenced based medicine and research initiatives including Comparative Effectiveness Research and other high priority research initiatives that align with the Nation’s agenda to improve the quality of care while reducing its costs.

The Transition of Care Initiative addresses improvements in care coordination and patient engagement in their own healthcare, in order that the strong foundation of Meaningful Use Stage 1 can be further strengthened with requirements for Meaningful Use Stage 2 that drive these improvements in care coordination and patient engagement. Transition of Care also contributes to major initiatives such as the Virtual Lifetime Electronic Record (VLER), Nationwide Health Information Network (NwHIN), Accountable Care Organizations, Patient Centered Medical Homes, and Bundled Payment Models that are all relevant to participating stakeholders.

The technical feasibility of this Initiative requires and supports information exchange. The Initiative specifically leverages existing interoperability standards; thus, many of the Healthcare Information Technology Standards Panel (HITSP) specifications (Appendix B) apply, as well as utilizing standards such as Health Level Seven (HL7) Continuity of Care Document (CCD and ASTM Continuity of Care Record (CCR)) developed by existing standard development organizations. Furthermore, it should be taken into account that Meaningful Use Stage 1 presents as an option that either the CCR or CCD could be utilized in the context of transition of care. The Initiative supports data flow which can be tested as exhibited by the fact that NIST has current test scripts available. The Transition of Care Initiative is accountable by aligning Stakeholders’ readiness level of use as well as attempting to improve general Health IT usability.

These Prioritization criteria coupled with existing relevant Use Cases (Appendix A) have rendered the basis for selection of the Transition of Care Initiative; thus, leveraging lessons learned that will be applied to the formulation of this Use Case.

2.4 Policy Issues
The Use Case strives to address relevant and timely policy issues that will have downstream impacts on the US healthcare reform agenda; specifically as related to healthcare information technology.

The Affordable Care Act mandates multiple pilots involving coordination of care, particularly at transitions. The primary policy issue at hand is the intention of the HIT Standards Committee to converge the clinical summary into a single standard. The Standards Committee has not confirmed that the HITSP C32/CCD will be the Base Standard. The current rule allows both CCD and CCR to be adopted.

The CCR and CCD do not have sections for discharge diagnosis; this potentially could be included in a transition of care [summary].

The User Story and Activity Diagrams represent a generalized flow of information exchange, but do not represent infrastructure, architecture, or workflow requirements. They show what information needs to go from place A to place B to achieve a clinically sound transfer of care for the patient; however, they dictate neither the information content format, nor the specific transactions for the transfer of this information. It is left to policy makers to determine what requirements are applied to eligible providers for transition of care.

2.5 Regulatory Issues
Implementation of the Transitions of Care Initiative supports the following regulatory requirements:

The Final Rule for Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology for Meaningful Use Stage 1 states the following:

//A. Initial Set of Standards, Implementation Specifications, and Certification for Electronic Health Record Technology (July 2010) identified the following standard for Engagement of Patients and Families in their Healthcare://

//__**(1) Electronic Copy of Health Information:**__ Electronic copy of health information. Enable a user to create an electronic copy of a patient’s clinical information, including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in: (1) Human readable format; and (2) On electronic media or through some other electronic means in accordance with: ``(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and (ii) For the following data elements the applicable standard must be used:// //**(A) Problems**.The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2);// //**(B) Laboratory test results.** At a minimum, the version of the standard specified in §170.207(c); and// //**(C) Medications.** The standard specified in §170.207(d) Electronic Copy of *Discharge Instructions: Electronic copy of discharge instructions enable a user to create an electronic copy of the discharge instructions for a patient, in human readable format, at the time of discharge on electronic media or through some other electronic means.//

//__**(2) *Electronic Copy of Discharge Instructions:**__ Electronic copy of discharge instructions. Enable a user to create an electronic copy of the discharge instructions for a patient, in human readable format, at the time of discharge on electronic media or through some other electronic means.//

//__**(3) Clinical Summaries for each Office Visit:**__ Clinical summaries enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list. If the clinical summary is provided electronically it must be: (1) Provided in human readable format; and (2) Provided on electronic media or through some other electronic means in accordance with: ``(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and (ii) For the following data elements the applicable standard must be used:// //**(1) Problems.** The standard specified in §170.207(a) (1) or, at a minimum, the version of the standard specified in §170.207(a) (2);// //**(2) Laboratory test results.** At a minimum, the version of the standard specified in §170.207(c); and// //**(3) Medications.** The standard specified in §170.207(d).//

//B. Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology (July, 2010) identified the following standard for Improvement in Care Coordination://

//(1) Enable a user to create an electronic copy of a patient’s clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, and procedures: (I) In human readable format, and (ii) on electronic media or through some other electronic means in accordance with: (A) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and (B) For the following data elements the applicable standard must be used://

//**(1) Problems.** The standard specified in §170.207(a) (1) or, at a minimum, the version of the standard specified in §170.207(a) (2);// //**(2) Procedures.** The standard specified in §170.207(b) (1) or §170.207(b) (2);// //**(3) Laboratory test results.** At a minimum, the version of the standard specified in §170.207(c); and// //**(4) Medications.** The standard specified in §170.207(d).//

//(2) Enable a user to create an electronic copy of a patient’s discharge summary in human readable format and on electronic media or through some other electronic means.//

2.6 Communities of Interest
Communities of Interest are public and private stakeholders that are directly involved in the business process or are involved in the development and use of interoperable implementation guides and in their actual implementation. Communities of Interest may directly participate in the exchange; that is, they are business actors; or indirectly through the results of the improved business process.

The following list of Communities of Interest and their definitions are for discussion purposes for Clinical Information Exchange. HISP organizations provide the technical capability to transmit the ToC messages across diverse EHR/PHR systems. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * **Member of Communities of Interest** || **Working Definition** ||
 * Patient || Members of the public who require healthcare services from ambulatory, emergency department, physician’s office, and/or the public health agency/department. ||
 * Consumers || Members of the public that include patients as well as caregivers, patient advocates, surrogates, family members, and other parties who may be acting for, or in support of, a patient receiving or potentially receiving healthcare services. ||
 * Care Coordinators || Individuals who support clinicians in the management of health and disease conditions. These can include case managers and others. ||
 * Clinicians || Healthcare providers with patient care responsibilities, including physicians, advanced practice nurses, physician assistants, nurses, psychologists, pharmacists, and other licensed and credentialed personnel involved in treating patients. ||
 * Laboratories || A laboratory (often abbreviated lab) is a setting where specimens are sent for testing and analysis are resulted, and then results are communicated back to the requestor. The types of laboratories may include clinical/medical, and environmental, and may be both private and/or public ||
 * Pharmacies || Entities that exist that are experts on drug therapy and are the primary health professionals who optimize medication use to provide patients with positive health outcomes ||
 * Provider || An individual clinician in a care delivery setting who requests, submits or accepts the transfer of the clinical summary for the purposes of delivering care ||
 * Provider Organizations || Organizations that are engaged in or support the delivery of healthcare to include Hospitals, Ambulatory Centers and Provider Practices. ||
 * Standards Organizations || Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical, and business needs for sharing information among organizations and systems ||
 * Federal Agencies || Organizations within the federal government that deliver, regulate or provide funding for health and health care ||
 * Electronic Health Record/Personal Health Record and HISP Vendors || Vendors which provide clinicians and consumers specific EHR/PHR solutions such as software applications and software services.

3.0 Challenge Statement
Meaningful Use Stage 1 and anticipated Stage 2 criteria require information to be exchanged in transitions of care. Implementers are often confused about how to adopt the specifications for exchange of the required data. The content of any exchange is only as good as its fidelity to source, assured identity, provenance, completeness, audit/traceability, full context, along with permissions and qualifications. Without ensuring these characteristics across information exchanges such that all are fully evident to the receiver (and ultimate user), no exchange is valid. Furthermore, this exchange is dependent on a secure, interoperable environment.

Different transition scenarios may require different types of artifacts (e.g. a transition from inpatient to ambulatory may require a discharge summary; a transition from primary care provider to specialist may require a referral summary, etc). All of these artifacts should draw from a common framework. As part of that framework, we should allow for different data elements to be communicated as needed. In all cases, the ToC transaction should support existing clinical workflows, and data overloading the recipient clinician must be avoided. Ultimately, the data needs of the patient and caregivers should be considered because it is the providers, patient (and/or their legal representative) that are the recipient end users of the data.

The exchange of clinical summaries is challenged by the selection of a single format for all transfers of care that does not support the various requirements for the data elements of different stakeholders, and diverse ToC circumstances. The current requirements that these all be communicated in either the CCD or CCR format may exclude data not supported by those standards. On the other hand, the use of a variety of formats for each different type of transfer of care would make it extremely difficult for systems to exchange and communicate the necessary data, and significantly delay this capability.

The challenge then is to:
 * Identify a “Core” data set that would be required in all ToC circumstances.
 * Identify the kinds of data beyond this “Core” data set needed for various transfers of care circumstances by all the stakeholders.
 * To define a uniform way of how to structure commonly used information.
 * To provide a robust tool-set to aid in the development and validation of conforming implementations to support widespread adoption.

4.0 Value Statement
The standardized patient clinical summary will provide timely, accurate, and structured information at the point of care to the receiving provider as well as offering enhanced clinical information to the patient. The accuracy and appropriate amount (the data required for the care of the patient without data overload) of clinical information will ensure that clinicians provide high quality care and patients will now become more involved and be informed of their care overall leading to a patient centric approach and patient empowerment. Enhancing a patient’s ability to make well informed decisions about their healthcare can be supported by the patient having access to their health information.

Defining the minimum data elements to be exchanged and mapping them to MU specified formats will facilitate this functionality becoming rapidly incorporated into certified EHR vendor offerings and better enable providers to use the specifications in a timely manner to exchange the required clinical data between care settings and with their patients.

5.0 Use Case Assumptions
Assumptions for this Use Case are the following:
 * A provider is an individual clinician in a care delivery setting who submits or receives the transfer of the clinical message for the purposes of delivering care. A provider organization is engaged in or supports the delivery of healthcare and includes Hospitals, acute care facilities, rehabilitation, SN facilities, and Ambulatory facilities.
 * The Transferring or Referring provider or Provider Organization has an EHR system capable of producing a structured summary document using C32/CCD and/or CCR standards and properly coded data elements; and can be exchanged with another EHR system or PHR system.
 * The EHR or PHR system is capable of ensuring that content of the Summary Record (as exchanged) maintains its fidelity to source, as well as assured identity, provenance, completeness, audit/traceability, full context, along with permissions and qualifications

The HISP providing the technical exchange services has established network and policy infrastructure to enable consistent, appropriate, and accurate information exchange across clinical systems, EHRs PHRs, data repositories (if applicable) and locator services. This includes, but is not limited to:


 * Methods to identify and authenticate users
 * Methods to identify and determine providers of care
 * Methods to enforce data access authorization policies
 * Security and privacy policies, procedures and practices are commonly implemented to support acceptable levels of patient privacy and security; i.e. HIPAA, HITECH and EHR certification criteria
 * The Patient has and uses a PHR
 * The transmission of data may occur via HISPs or Health Information Exchanges as data may be transmitted to multiple EHRs, HIEs and providers
 * Some exchanges may require HISP to HISP connectivity

//Appendix C provides more details on Privacy and Security assumptions.//

6.0 Pre-Conditions
Pre-conditions are those conditions that must exist for the implementation of the ToC interoperability Information Exchange.
 * To ensure the Summary Record maintains its fidelity to source, assured identity, provenance, completeness, audit/traceability, full context, along with permissions and qualifications-both as a pre-condition of transmittal/disclosure (source/sending EHRs/PHRs) and of receipt (receiving EHRs/PHRs).
 * PHR and EHR systems are in place.
 * The Patient is registered in all systems.
 * The Provider has treated the Patient or has been requested to treat the patient by another provider.
 * Relevant clinical information will be exchanged which will include at a minimum “Core”, and may include “Variable” data.
 * There are methods to ensure the veracity of data.
 * Clinicians securely access clinical information through an EHR system.
 * Patients may securely access clinical information through a PHR system.
 * Appropriate standards protocols; patient identification methodology; consent; privacy and security procedures; coding, vocabulary and normalization standards have been agreed to by all relevant participants.
 * Legal and governance issues regarding data access authorizations, data governance, and data use are in effect.

7.0 Post Conditions
Post Conditions are those conditions that exist after the Clinical Information Exchange.
 * Clinical Information is successfully reported and electronically transmitted between Sending Provider to Receiving Provider or Patient PHR and (1) is accessible by the Receiving Provider/Patient through an EHR/PHR system and (2) is displayed in a human readable format.
 * Clinical Information is accessible by the Electronic Health Record application.
 * Clinical Information is accessible by the Personal Health Record application.

8.0 Actors and Roles
This section describes the Business Actors that are participants in the information exchange requirements for each scenario. A Business Actor is an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete Use Case action(s); a Business Actor may be a Stakeholder. Furthermore, the systems perform specific roles in this Use Case as listed below:
 * **Actor** || **System** || **Role** ||
 * Provider (Person) || Electronic Health Record (EHR) System || Sender/Receiver or Source/Destination ||
 * HISP || Health Information Service Provider || The “wire” across which the health information is sent from the sender to the receiver ||
 * Patient || Personal Health Record (PHR) System || Sender/Receiver or Source/Destination ||
 * Provider Organization || Electronic Health Record (EHR) System || Sender/Receiver or Source/Destination ||
 * Caregivers || Personal Health Record (PHR) System || Sender/Receiver or Source/Destination ||

9.0 Use Case Diagram
The following diagram depicts the exchange to support the Elements in Transition of Care Use Case.
 * 1) The ability of the Electronic Health Record System to send and/or receive Clinical Information.
 * 2) The ability of the Personal Health Record to send and/or receive Clinical Information.



10.0 Scenario 1: The Exchange of Clinical Summaries from Provider to Provider.
As described in the Scope section, the Use Case has two scenarios: the first focuses on the perspective of provider to provider exchange of clinical summaries. The second focuses on the perspective of the providers sending these clinical summaries to patients and their PHR. Both scenarios share the same User Stories. However, the User Story in the first scenario is presented from the provider to provider perspective and the second scenario is presented from the provider to patient perspective. Thus both scenarios are based on the same User Stories and activities, just presented from the two perspectives. The actual instance of any of the User Stories and activities may include both perspectives.
 * Introduction to Scenarios **


 * Assumptions**:
 * 1) The receiving facility may have provisionally accepted the patient for transfer or referral and wants the clinical summary, but this is not necessary for the sending facility to push the ToC information.
 * 2) Informal negotiations between providers are out of scope and are not necessary to assure acceptance of transfer or referral.
 * 3) Informal agreement to receive by other provider and by patient is necessary for actual transfer or referral of patient. Similarly informal agreement to receive the clinical information by the other provider and by the patient is necessary for information exchange to take place, as is traditional in current actual medical practice.
 * 4) Scenario 1 does not describe transport or end user site activity.
 * 5) The information exchange can be achieved with or without intermediaries. If the information is transferred via a HISP signed patient consent is not required. Using intermediaries such as an HIE requires signed patient consent in most states. Same assumptions apply to Scenario 1 and 2.

10.1 User Stories of Scenario 1
The User Stories illustrate a combination of events in the scenario flows which are described in further detail in the tables that follow.

NOTE: The discharge instructions described above are also part of the discharge summary. If the discharge summary is ready at the time of physical discharge, it should be sent to the PCP or patient's care team.

A patient is discharged from the hospital or ED. Discharge instructions are given to the patient by hospital personnel at the time of discharge. The instructions may be generic, patient specific, or disease specific depending on the facility’s practices and the patient’s needs. The patient acknowledges that he has received the instructions from the hospital personnel (verbally, in writing, or electronically). The acknowledgement triggers the physical discharge sequence of events and patient transport out of the facility. The discharge summary (which includes the discharge instructions) is also sent to the patient's Primary Care Physician (PCP) or Care Team (as the instructions may contain information necessary for the PCP or Care Team to follow up with the patient before the discharge summary is available). Upon discharge, the discharge summary is prepared within the Hospital EHR system. The attending physician of record (APoR) reviews the discharge summary (or instructions) and, once she has approved it, the discharge summary is sent to the PCP. The summary may arrive in the PCP’s EHR system even before the patient has left the hospital. A copy of the message may be retained in the hospital EHR per the hospital’s policies and workflow rules.
 * User Story 1: The Exchange of Information to Support the Transfer of Patient Information from One Provider to Another**
 * Actors**:
 * **Actor** || **Role** ||
 * Provider: Hospital or ED Clinical System || Source ||
 * Provider: Patient's PCP or Care Team || Destination ||
 * Setting 1: Hospital or Emergency Department from where patient is discharged (sends discharge summary to PCP or Care Team).**

Audit logs of the exchange are retained according to the hospitals, PCP’s, and any intermediaries’ policies, procedures, and agreements.

Discharge summary/instructions are received into the PCP practice’s EHR system. Patient generally will be known in the EHR system in which case an automated EHR match may occur). Discharge summaries/instructions that are not automatically matched to a patient are reconciled manually, which may include the process of creating a new patient record and registering the patient. Once the discharge summary/instructions have become part of the PCP’s EHR system, additional practice variable activities may occur: new tasks may be directed to a front desk staff EHR work queue, as well as to additional staff EHR work queues as appropriate to the practice workflows. Follow-up/plan of care is managed according to established PCP workflow. For example, upon receiving notification of the patient’s status, the care manager is now aware that the patient has been discharged from the hospital. The Care Manager may be aware that the patient becomes confused when medications are altered and calls the patient to ensure the patient is taking the correct medications post discharge and is following the discharge instructions.
 * Setting 2: Patient's PCP or Care Team (receives discharge summary from Hospital or ED clinical system).**

The PCP may review and promote into the EHR the newly reconciled active medications, updated problem lists, new procedures and other discrete data elements. The hospital (or ED) discharge summary/instructions are retained in its entirety as a permanent part of the patient’s record.


 * User Story 1 could also be applied to a specialist sending reports back to PCP for follow-up post op or post discharge.


 * User Story 2: Closed Loop Referral**


 * Actors**
 * **Actor** || **Role** ||
 * Provider; PCP's EHR System || Referral Source ||
 * Provider; Specialist's EHR System || Referral Destination ||

A PCP is in the middle of an encounter (office visit) with a patient and determines that the patient needs to be referred to a specialist. The PCP is documenting the encounter in the EHR and within the EHR prepares the consultation request clinical summary for the specialist. The message is addressed to the appropriate specialist, specialty or provider organization and is sent to the specialist’s EHR system. In all cases the message will include the “Core” data and ideally will also include selective “Pertinent” data.
 * Setting 1: PCP's office (sends consultation request clinical summary to specialist).**

The consultation request clinical summary is processed according to the specific context of the referral. In accordance with practice policies and workflow the specialist reviews the document and orders any additional tests to be performed for the patient prior to the office visit. Discrete data elements from within the summary may be promoted to the specialist’s EHR system (date time and source stamped).
 * Setting 2: Specialist's office (receives referral request clinical summary from PCP; send consultation summary to PCP).**

When the patient arrives at the specialist’s office he is registered in accordance with practice policies and workflow. The specialist documents the encounter in the EHR system and prepares the consultation summary for the PCP. Once the consultation summary is prepared, it is addressed and sent to the PCP’s EHR system. A copy of the message is retained in the specialist’s EHR system


 * User Story 2 could also be applied to a specialist sending reports back to PCP for follow-up post op or post discharge.

The consultation summary is received into the PCP practices’ EHR system. Once the consultation summary is received into the EHR system, additional practice variable activities may occur: tasks can be directed to a front desk staff EHR system work queue for appropriate distribution to additional staff’s EHR system work queues, as appropriate to the practice workflows. For example, the front desk staff may schedule a follow-up visit with the patient and alert the PCP of the availability of the consultation summary. If the patient has an assigned Care Manager who follows the patient at an advanced practice care facility (such as a Patient-Centered Medical Home), review alerts may be sent to both the PCP and the Care Manager for appropriate compliance planning. Discrete data elements from within the consultation summary may be promoted to the PCP’s EHR system. In accordance with practice policies and EHR functionality, the PCP may review and promote to the EHR the specialist-reconciled active medication and problem lists, any new procedures may be accepted into the EHR, and any other new discrete data elements may become part the of the patient’s EHR 9all date/time/source stamped). The consultation summary may be retained in its entirety as a permanent part of the patient’s EHR record.
 * Return to Setting 1: PCP’s office**


 * User Story 3: Complex Series of Care Transactions**


 * Setting**: Emergency Department


 * Activity**: A patient is transported to the ED from home in a semi-comatose condition. Their significant other has printed data from the patient’s PHR and has given that to the EMS to give to the ED doctor. The patient is admitted to the ED. The ED EHR system receives the patient summary from the patient’s PCP’s EHR system. The ED physician determines that the patient needs to be admitted to the hospital. The patient is admitted to the hospital’s critical care unit. As the ED and the Hospital share the same EHR system the data, once entered into the system, is available to all appropriate end users caring for the patient.


 * Summary Contents: Both basic standard dataset and patient summary message context relevant dataset-APPLIES TO ALL Transitions of Care (Basic data set and pertinent data set to not data overload the recipient clinicians).**

Message should always include //Core// basic dataset:
 * Demographic information, active medication list (with doses and sig), allergy list, problem list, etc.

Summary contains //variable dataset relevant to the context//:
 * Examples: Recent results, vitals, etc.


 * Setting**: Hospital


 * Activity**: A patient is cared for in a critical care unit. All treating clinicians have access to the information in the Hospital EHR system. The patient’s significant other, who is the patient’s Durable Power of Attorney for Healthcare (DPOA-HC), is staying with the patient in the hospital. The patient’s DPOA-HC requests that copies of changes to patient’s orders be sent directly from the hospital EHR to the patient’s PHR so that he/she can monitor the patient’s care. After several days in the intensive care unit it is determined that the patient would benefit from intensive rehabilitation that is not available at the hospital. The attending physician arranges a discharge from the hospital and transfer for the patient to a Rehabilitation Facility. In accordance with the hospital’s policies and workflow a discharge summary & instructions are prepared by the hospital EHR. The discharge summary and instructions, including recommendations for continuation of open orders, are sent to the Rehab facility EHR. The hospital EHR sends patient’s PCP’s EHR a copy of discharge summary/instructions.

Upon discharge from hospital, the patient is transferred to a rehabilitation facility. The TOC discharge information is transferred via a HISP to the recipient facility prior to the patient leaving the hospital.


 * Summary Contents: Both basic standard dataset and Discharge context relevant dataset**

Summary should always include //Core// basic dataset: Summary contains //variable dataset relevant to the hospitalization (selected by the clinician who prepared the discharge message)://
 * Demographic information, active //reconciled// medication list (with doses and sig), allergy list, problem list, reason for admission, follow up/discharge instructions etc.
 * Examples:
 * Procedures during hospitalization
 * Relevant results, reports
 * Wound care (if applicable)
 * Speech, Occupational & Physical Therapy orders and Activities of Daily Living (ADL) evaluations
 * Etc.


 * Setting**: Rehabilitation Facility


 * Activity**: The hospital discharge summary/instructions are received in the Rehab facility's EHR system. When the patient arrives she is admitted and the EHR is updated. The EHR system provides the patient information for review by the hospital personnel that will be caring for the patient. Once reviewed and approved by the clinicians in accordance with the facility’s policies, protocols and workflows, the information is available to all of the rehab staff that will be caring for the patient. The patient’s PHR receives copies of rehab case review notes and ADL evaluations so that the DPOA-HC can actively monitor the patient’s progress and assist in planning patient’s discharge destination post-rehab.

Upon completion of the rehabilitation, the patient is discharged to home/PCP. At this point in time the patient’s PCP receives a discharge summary ToC document at the time the patient is being discharged from this facility prior to the patient physically being out the door. – see User Story 1.

Summary should always include //Core// basic dataset: The Summary contains variable dataset relevant to the rehab care plan.
 * Summary Contents: Both basic standard dataset and Discharge context relevant dataset**
 * Demographic information, active //reconciled// medication list (with doses and sig), allergy list, problem list, reason for admission,
 * Examples might include:
 * Therapy orders
 * ADL scores

**10.1.1 Base Flow of Scenario 1**

 * User Story 1: The Exchange of Discharge Summary to Support the Transfer of Patient Information from One Provider to another Provider.**
 * **Step #** || **Actor** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Provider || Trigger Generation of Discharge Summary for Patient A || START || Discharge Instructions ||
 * 2 || Hospital EHR System || Send Discharge summary to PCP's EHR System or other Provider EHR System || Discharge Instructions || Discharge Instructions ||
 * 3 || PCP EHR System or other Provider EHR System || Receive Discharge Summary || Discharge Instructions || Discharge Instructions ||
 * 4 || Provider || Trigger Generation of Discharge Summary for Patient A

(includes Discharge Instructions) || Discharge Summary || Discharge Summary ||
 * 5 || Hospital EHR System || Send Discharge summary to PCP's EHR System or other Provider /Organization || Discharge Summary || Discharge Summary ||
 * 6 || PCP EHR System or other Provider EHR System || Receive Discharge Summary || Discharge Summary || Discharge Summary ||
 * 7 || Provider || View Discharge Summary/Instructions || Discharge Summary || END ||


 * User Story 2: The Exchange of Clinical Summaries to Support the Closed Loop Referral of a Patient from One Provider to Another**
 * **Step #** || **Actor** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Provider || Trigger Generation of Consultation Request Clinical Summary for Patient A || START || Generated Consultation Request Clinical Summary ||
 * 2 || PCP EHR System || Send Consultation Request Clinical Summary to specialist's EHR System || Consultation Request Clinical Summary || Consultation Request Clinical Summary ||
 * 3 || Specialist EHR System || Receive Consultation Request Clinical Summary from PCP's EHR System || Consultation Request Clinical Summary || Consultation Request Clinical Summary ||
 * 4 || Provider || View Consultation Request Clinical Summary in specialist's EHR System || Consultation Request Clinical Summary || END ||
 * 5 || Provider || Trigger Generation of Consultation Summary for patient A || START || Generated Consultation Summary ||
 * 6 || Specialist EHR System || Send Consultation Summary to PCP's EHR System || Consultation Summary || Consultation Summary ||
 * 7 || PCP EHR System || Receive Consultation Summary from specialist's EHR System || Consultation Summary || Consultation Summary ||
 * 8 || Provider || View Consultation Summary in PCP's EHR System || Consultation Summary || END ||


 * User Story 3: Complex Series of Care Transitions (//Note: Events of this User Story are reflected in the Simple ToC User Story//)**

**10.1.2 Activity Diagram for Scenario 1**
The following are the Activity Diagrams to support the events in section 10.1.1.


 * User Story 1: The Exchange of Discharge Summary to Support the Transfer of Patient Information from One Provider to Another Provider.**




 * User Story 2: The Exchange of Clinical Summaries to Support the Closed Loop Referral of a Patient from a One Provider to Another.**

**10.2.1 Information Interchange Requirements of Scenario 1**
(A.XFER.1) || Consultation Request Clinical Summary || Receives (A.XFER.2) || Specialist EHR System || And or Procedure/operative note || Receives (A.XFER.2) || PCP EHR System ||
 * **Initiating System** ||  || **Information Interchange Requirement Content** ||   || **Receiving/Responding System** ||
 * Hospital/ED EHR System || Send (A.XFER.1) || Discharge Summary || Receives (A.XFER.2) || PCP EHR System ||
 * PCP EHR System || Send
 * Specialist EHR System || Send (A.XFER.1) || Consultation Summary

**10.2.2 System Requirements of Scenario 1**

 * **System Requirement Name** || **System** ||
 * Display Discharge Summary || PCP EHR System ||
 * Display Consultation Request Clinical Summary || Specialist EHR System ||
 * Display Consultation Summary || PCP EHR System ||

10.3 Sequence Diagrams of Scenario 1
The following sequence diagrams describe the messages and order of messages.


 * User Story 1: The Exchange of Discharge Summary to Support the Transfer of Patient Information from One Provider to Another Provider.**


 * User Story 2: The Exchange of Clinical Summaries to Support the Closed Loop Referral of a Patient from a One Provider to Another**
 * ``*``*``*``*``*PLEASE NOTE: The downloading of Patient Information to the PHR is included in Scenario 2: Exchange of Clinical Summaries between Provider to Patient.``*``*``*``*``***

11.1 User Stories of Scenario 2

 * The visuals below depict a combination of all events described in the scenario flows which are described in further detail in the tables that follow.**

**//(Refer to sections highlighted in red and italicized, which are the focus of this scenario)//**


 * Assumption**: Scenario 2 does not describe transport or end user site activity.


 * User Story 1: The Exchange of Discharge Instructions and Discharge Summary between a Provider and Patient to Support the Transfer of a Patient from One Care Setting to Another.**


 * Actors**
 * **Actor** || **Role** ||
 * Provider: Any Provider EHR System || Source ||
 * Patient: The Patient's PHR System or Patient Portal || Destination ||

A patient is discharged from the hospital or ED. Discharge instructions are given to the patient by his hospital personnel at the time of discharge. The instructions may be generic, patient specific, or disease specific depending on the facility’s practices and the patient’s needs. The patient acknowledges that he has received the instructions from the hospital personnel (verbally, in writing, and/or electronically). The acknowledgement triggers the physical discharge sequence of events and patient transport out of the facility. //The discharge instructions are sent to the patient’s PHR// and to the patient's primary care physician (PCP) or Care Team (as the instructions may contain information necessary for the PCP or Care Team to follow up with the patient before the discharge summary is available). Upon discharge, the discharge summary is prepared within the Hospital EHR system. The attending physician of record (APoR) reviews the discharge summary and, once approved, the discharge summary is sent to the PCP. The summary may arrive in the PCP’s EHR system even before the patient has left the hospital. A copy of the message may be retained in the hospital EHR per the hospital’s policies and workflow rules. //The discharge summary, or portions thereof, may also be sent to the patient’s PHR system.//
 * Setting 1: Hospital or ED from where patient is discharged (sends discharge instructions to patient).**

**NOTE: The discharge instructions described above are also part of the discharge summary. //__Depending on the workflow, and the policies at the hospital or ED, the patient and patient’s PHR may receive only the discharge instructions at discharge. The discharge summary may be provided later upon request and within 36 hours of discharge.__//**

Audit logs of the exchange are retained according to the hospital’s PHR systems, and any intermediaries’ policies, procedures, and agreements.

//The patient discharge instructions and discharge summary are received by the patient’s PHR system. Depending on the specific PHR application, the patient or home health agency (HHA) receives a notification to access and review the PHR. The patient (or patient’s authorized proxy) accesses the PHR and may review the patient discharge instructions. Again, depending on the PHR system's functionality the patient or proxy may be able to select sections within the discharge instructions (discrete data elements) to automatically populate the appropriate fields in the PHR. For example, the newly reconciled medication list is selected to upload to the active medication list section of the PHR and the patient uploads any new problems to the problem list. Some information may be selected to initiate the agency workflow process. The PHR system may also receive the discharge summary. In that case please see the "Closed Loop Referral" User Story about handling the receipt of a medical summary in the PHR system.//
 * Setting 2: Patient**


 * User Story 2: The Exchange of Clinical Summaries between Provider and Patients to Support the Closed-loop Transfer of a Patient from One Care Setting to Another Consultation Referral.**


 * Actors**
 * **Actor** || **Role** ||
 * Provider: Any Provider EHR System || Source ||
 * Patient: The Patient's PHR System or Patient Portal || Destination ||


 * Setting 1: PCP’s office**


 * Activity**: Primary Care Physician is in the middle of an encounter (office visit) with a patient and determines that the patient needs to be referred to a specialist. The PCP is documenting the encounter in the EHR and within the EHR prepares the consultation request clinical summary to the specialist. The summary is addressed to the appropriate specialist, specialty or provider organization and is sent to the specialist’s EHR system.

**//The consultation request, clinical summary, or portions thereof may also be sent to the patient’s PHR system.//**


 * Setting 2:** **Specialist’s office**


 * Activity**: The consultation request clinical summary is processed according to the specific context of the referral. In accordance with practice policies and workflow the specialist reviews the document and orders any additional tests to be performed for the patient prior to the office visit. Discrete data elements from within the summary may be promoted to the specialist’s EHR system, date/time/source stamped.

When the patient arrives at the specialist’s office he is registered in accordance with practice policies and workflow. The specialist documents the encounter in the EHR system and prepares the consultation summary to the PCP. Once the consultation summary is prepared it is addressed and is sent to the PCP’s EHR system. A copy of the summary is retained in the specialist’s EHR system. **//The consultation summary will include “Core” data, and may include “variable” data.//**

**//The consultation summary may also be sent to the patient’s PHR System.//**

**NOTE: The return to PCP office is only needed in Scenario 1 for the receiving of the consultation summary by the PCP. In Scenario 2 there is not provider/patient exchange of information as part of Transition of Care in the return to Setting 1.**


 * Setting 3: Patient**


 * Activity**: **//"Consultation summary" is received by the patient’s PHR system.//** //Depending on the specific PHR system, the patient may receive a notification to access his PHR as there is new information available. The patient (or the patient’s authorized proxy) accesses the PHR and may review the consultation request clinical summary. The patient (or his proxy) may respond with questions. Again, depending on the PHR system's functionality the patient may be able to select sections of the consultation request clinical summary (that are discrete data elements) to automatically populate the appropriate fields in the PHR. For example, the patient may upload any new problems to the problem list. Other PHR systems may have “all or none” functionality allowing the patient to simply determine if he would like to retain or delete the consultation request clinical summary in the PHR system.//

**11.1.1 Base Flow of Scenario 2**
Request || Discharge Instructions ||
 * User Story 1: The Exchange of Discharge Instructions between Provider and Patient to Support the Transfer of a Patient from One Care Setting to Another.**
 * **Step #** || **Actor** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Provider || Order/Address/Request: Discharge Summary and Discharge Instructions to Patient A in EHR (and has been acknowledged by patient) || START || Discharge Summary and Discharge Instruction Request ||
 * 2 || EHR System || Generate and Send: Discharge Instructions to PHR || Discharge Instructions
 * 3 || PHR System || Receive: Discharge Instructions in PHR || Discharge Instructions || Discharge Instructions ||
 * 4 || EHR System || Generate and Send: Discharge Summary to PHR || Discharge Summary Request || Discharge Summary ||
 * 5 || PHR System || Receive: Discharge Summary in PHR || Discharge Summary || END ||


 * User Story 2: The Exchange of Clinical Summaries between Provider and Patients to Support the Closed-loop Consultation Referral.**
 * **Step #** || **Actor** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Provider (PCP) || Order/Address/Request: Consultation request while meeting with patient || START || Initiated Consultation Request ||
 * 2 || EHR System || Generate and Send: Consultation request summary || Initiated Consultation Request Summary || Consultation Request Summary ||
 * 3 || PHR System || Receive: Consultation Request Summary in PHR || Consultation Request Summary || Consultation Request Summary ||
 * ||  || **//Note: rows 4-6 will occur for any delivery of a Clinical Summary//** ||   ||   ||
 * 4 || Provider || Order/Address/Request: Clinical Summary including specialist’s summary || START || Initiated Clinical Summary Request ||
 * 5 || EHR System || Generate and Send: Clinical Summary details || Initiated Clinical Summary Request || Clinical Summary ||
 * 6 || PHR System || Receive: Clinical Summary in PHR || Clinical Summary || Clinical Summary ||

**11.1.2 Activity Diagrams for Scenario 2**
The following are the Activity Diagrams that support the events in section 11.1.1.


 * User Story 1: The Exchange of Discharge Instructions and a Discharge Summary between a Provider and a Patient to Support the Transfer of a Patient from One Care Setting to Another.**


 * User Story 2: The Exchange of Clinical Summaries between Provider and Patients to Support the Closed-loop Consultation Referral**

**11.2.1 Information Interchange Requirements of Scenario 2**

 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving/Responding System** ||
 * Electronic Health Record System || Send (A.XFER.1) || Discharge Summary || Receives (A.XFER.2) || Personal Health Record System ||
 * Electronic Health Record System || Send (A.XFER.1) || Discharge Instructions || Receives (A.XFER.2) || Personal Health Record System ||
 * Electronic Health Record System || Send (A.XFER.1) || Consultation Request Summary || Receives (A.XFER.2) || Personal Health Record System ||
 * Electronic Health Record System || Send (A.XFER.1) || Clinical Summary || Receives (A.XFER.2) || Personal Health Record System ||

**11.2.2 System Requirements of Scenario 2**

 * **System Requirement Name** || **System** ||
 * Display Discharge Summary || Personal Health Record System ||
 * Display Discharge Instructions || Personal Health Record System ||

11.3 Sequence Diagrams
The following sequence diagrams describe the messages and order of messages.


 * User Story 1: The Exchange of Discharge Message (Discharge Instructions and Discharge Summary) to Support the Transfer of a Patient from One Care Setting to Another**


 * User Story 2: The Exchange of Clinical Summaries between Provider and Patient to Support the Closed-loop Consultation Referral**

12.0 Issues and Obstacles
In general, the absence of the pre-conditions described in the previous section presents obstacles to implementation of the Use Case. Additional obstacles are provided below:
 * Variations in local, state and national security and privacy regulations, and other pertinent laws.
 * There are regulations concerning the storage, transmission, or destruction of electronic health information. These regulations are inconsistent across federal, state, and local jurisdictions.
 * Lack of harmonization among data interoperability standards including vocabulary and other messaging standards.
 * Without consistent standards, the viewing, accessing, or transmitting of electronic health information may be inhibited. Certainly the eventual ability to seamlessly upload discrete data from one EHR system to another would be inhibited
 * Incomplete and or inaccurate data or proprietary-formatted information prevents information exchange activities; Consulting Provider may not be able to receive the data
 * A lack of EHR and PHR adoption
 * A lack of a sustainable business model and pervasive infrastructure to enable electronic data exchange.
 * Policies do not exist for a patient’s ability to understand and control clinical information when using a PHR.
 * [We had addressed this and commented that it is out of scope and would be up to the PHR edge vendor system]
 * There is limited integration of PHRs with provider workflows.
 * State Laws regarding laboratory results.

13.0 Dataset Considerations
The following summaries are described in the previous user stories:
 * Discharge Summary
 * Discharge Instructions
 * Clinical Summary including Consultation Request
 * Clinical Summary

The Sub-Workgroup did not describe standard content of summaries such as:
 * Patient identity [This was included in the Core data set under patient demographics]
 * Data to insure transport of the content Provider Directories
 * Security, auditing and other policy content
 * Other procedural overhead, etc.

The following tables describe the sections and data expected to be found in these clinical summaries:
 * All of the data in the tables may not be clinically relevant in all situations. Data that is not clinically relevant to a particular ToC circumstance would simply not be “selected” by the sending provider – This is assuming that this would be a GUI design element in EHR systems upon which EHR vendors would compete pertaining to this functionality.
 * Some clinical situations may require additional data not included in the tables [e.g. currently not captured in EHR systems or if captured, not captured as discrete data, but captured as free text]
 * Meaningful Use may only require a subset of the data


 * Dataset for Discharge Instructions:**

Discharge Instructions always includes standard basic dataset:
 * Demographic information, active medication list (with doses and sig), allergy list, problem list.

Discharge Instructions contains also dataset relevant to the discharge summary/discharge instructions context:
 * This will depend on what the sending clinician deems as relevant and may include: Follow up/plan of care (e.g., CCD/83 Plan of Care (What patient can do)): Prospective sections (Treatment Plan), treatments, diet, activities, alerts for conditions, future visits (may include several depending on condition) including appointment established. Patient education and information on medication (tied to alerts), disease process, wound care, condition based special considerations, etc.) etc.

Message contains variable dataset relevant to the hospitalization (selected by the clinician who prepared the discharge summary): Substance intolerance Associated Adverse Events || List of allergies which might include allergy to what (e.g., medication. food, environment). Sensitivity. Past and those that have arisen || Whether a Healthcare Proxy has been invoked || 1. Goals. 2. Results yet to be received and procedures to be followed up on. 3. Active and scheduled interventions and orders (short term direct instructions [e.g. Vital sign checks, labs, etc.] - in the long run as validated by the patient and those contributed by the patient/caregiver). 4. Education Resources/Materials - Patient education needed. To include classes, educational sessions, and printed materials along with steps to a specific need. 5a. Diet and Diet/Fluid Restrictions: All instructions that describe the expected diet. b. Restrictions: List of limitations being placed on the diet 6a. Fluids Management (C/N): All instructions that describe the expected fluids and method of administration. b. Restrictions: List of limitations being placed on fluids 7. Activity/Exercise **NOTES. Instructions may be more detailed if sent to another provider.** - Yes/No - has the discharge instruction been reviewed with the patient? - Yes/No - has the discharge instruction been accepted by the patient, if no then how addressed ||
 * Examples
 * Procedures during hospitalization
 * Selected medications administered during hospitalization
 * Selected vital signs
 * Emergency contact information
 * Relevant results, reports
 * Wound care (if applicable)
 * Etc.
 * **Ref. || Section || Content || Additional Notes ||
 * T.CC.1 || Personal Information || Name, DOB, Next of Kin, Address, Phone Number, Gender, Marital Status, Religion, Race, Ethnicity ||  ||
 * T.CC.5 || Allergies and Other Adverse Reactions || Allergy Type; and Date
 * T.CC.6 || Problem List || Current Diseases & Conditions monitored for the patient and status || * List of problems/complaints (what was diagnosis, complaint and/or descriptor of problem/complaints, symptoms).
 * How do these problems/complaints impact interventions, orders or instructions. ||
 * T.CC.16 || Hospital Discharge Medications || Medications names, doses, frequency, route ordered for the patient for after discharge. || * Include the reconciled active medications including time of last dose and whether patient was sent with samples of the medication(s).
 * **NOTES. Instructions may be more detailed if sent to another provider.** ||
 * T.CC.18 || Advance Directives || Yes/no, whether or not these exist || Yes/No - Target is to trigger a conversation.
 * T.CC.20 || Immunizations || Immunizations name, dose, route, date administered to the patient || Comprehensive list of immunizations received during the hospital stay ||
 * T.CC.21 || Plan of Care || Proposed interventions and procedures for patient || Subsections include the following (1-7)
 * T.CC.22 || Medical Equipment - includes assistive devices and is related to functional status || Implanted and External Medical Devices; Dates || * List of devices and where the device is to be secured/prescribed/embedded.
 * Duration of medical devices.
 * History of devices (recalls, S/N, etc.)
 * Includes reading glasses, hearing aids, dental appliances, etc. ||
 * ADDED || Patient Risks || Falls, Elopement, etc || * Strategies to mitigate patient risks ||
 * ADDED || Risks to Others || Contagion, Violent behavior || * Isolation Requirements, etc ||
 * ADDED || Electronic Links ||  || Links to provider or other computer applications for patient results, summaries, etc. ||
 * ADDED || Patient Oriented Embarkation Checklist ||  || List of facility dependent patient oriented items (e.g., pain scale at discharge, last ECG, etc.) ||
 * ADDED || Functional Status (O/N) - ||  || End state/goal expressed/Projected change in functional status (will relate to the goals identified) ||


 * Dataset for Discharge Summary:**

Discharge Summary Contents: Both basic standard dataset and discharge context relevant dataset are determined by the discharging provider organization in accordance with the discharging provider, local policy, regulations and law. The receiving provider through its EHR system may determine how to incorporate and present the Discharge Summary.

Notwithstanding the Discharge Summary should always include the core dataset. At discharge the summary might include content for the Discharge Instruction as well as Discharge Summary. Discharge Summary content includes:
 * Demographic information, active reconciled medication list (with doses and sig), allergy list, problem list, and reason for admission.

Message contains variable dataset relevant to the hospitalization (selected by the clinician who prepared the discharge message). Examples:
 * Procedures during hospitalization
 * Relevant results, reports
 * Wound care (if applicable)
 * Etc.

Hospital and ED discharge is also the focus of several other efforts including individuals and institutions involved in ToC. For instance, the HIE Challenge Grants, Improving Massachusetts Post-Acute Care Transfers (IMPACT). Input was provided by Keith Boone; [|(http://motorcycleguy.blogspot.com/2010/11/circle-never-ends.html)]. Consideration was given to HITSP C32 Version 2.5, Meaningful Use EHR certification requirement and CDA Consolidation. Along with input from the Use Case Simplification and Discharge Instruction Sub Workgroups the following recommended sections and data are included in the Discharge Summary. The sections with a are also found in the HITSP C48 Encounter Document Using IHE Medical Summary (XDS-MS) Component. Active Problems (R/N)/Chief Complaint (overriding problem at the time of discharge) - chronic illness and congenital problems || Current Diseases & Conditions monitored for the patient and status || * List of problems/complaints (what was diagnosis, complaint and/or descriptor of problem/complaints, symptoms). ||
 * **Ref. || Section || Content || Additional Notes ||
 * T.CC.1 || Personal Information [[image:Check_mark.JPG]] || Name, DOB, Healthcare Power of Attorney, Address, Phone Number, Gender, Marital Status, Religion, Race, Ethnicity ||  ||
 * T.CC.2 || Contact Information || Contact Name, Contact Number ||  ||
 * T.CC.3 || Insurance Information || Insurance Name, Phone #, Group #, Type, Member #, Subscriber Name, Financial responsibility ||  ||
 * T.CC.4 || Healthcare Provider || Provider Name, Address, Phone Number, Type ||  ||
 * T.CC.5 || Allergies and Other Adverse Reactions [[image:Check_mark.JPG]] || Allergy Type; and Date || List of allergies which might include allergy to what (e.g., medication. food, environment) ||
 * T.CC.6 || Problem List
 * T.CC.7 || History of Past Illness || Diseases & Conditions Patient has suffered in the past ||  ||
 * T.CC.8 || Chief Complaint (see change in T.CC.6 Problem List) || Description of Patient's Complaint (narrative) ||  ||
 * T.CC.9 || Reason for Transfer || Reason Patient is being referred ||  ||
 * T.CC.10 || History of Present Illness [[image:Check_mark.JPG]] || Sequence of events proceeding patient's disease/condition ||  ||
 * T.CC.11 || List of Surgeries || List of types of surgeries and dates ||  ||
 * T.CC.12 || Hospital Admission Diagnosis [[image:Check_mark.JPG]] || List of Hospital Diagnosis and dates ||  ||
 * T.CC.13 || Discharge Diagnosis [[image:Check_mark.JPG]] || Conditions/Diseases identified during hospital stay and dates ||  ||
 * T.CC.14 || Medications || List of Current Medication Names ; date, route, dose, frequency || * Include the reconciled active medications ||
 * T.CC.15 || Admission Medications History [[image:Check_mark.JPG]] || List of historical medication names, dose, route, frequency, date patient has taken previously ||  ||
 * T.CC.16 || Hospital Discharge Medications [[image:Check_mark.JPG]] || Medications names, doses, frequency, route ordered for the patient for after discharge ||  ||
 * T.CC.17 || Medications Administered [[image:Check_mark.JPG]] || Medications administered to patient during the course of an encounter; name, dose, route, frequency ||  ||
 * T.CC.18 || Advance Directives [[image:Check_mark.JPG]] || A summary of patient's expectations for care || * Yes/No, if Yes date of last known
 * Yes/No if **Physician Orders for Life-Sustaining Treatment (**POLST) form returned
 * Where is last known version/original is located ||
 * T.CC.19 || Pregnancy || Pregnant, Yes/NO ||  ||
 * T.CC.20 || Immunizations || Immunizations name, dose, route, date administered to the patient || Comprehensive list of immunizations received during the hospital stay. ||
 * T.CC.21 || Physical Examination [[image:Check_mark.JPG]] || Physical Findings of the Patient; VS, Biometrics, Review of Systems ||  ||
 * T.CC.22 || Vital Signs - Vital Signs (R/N) including Pain Scale Assessment, Smoking Status [[image:Check_mark.JPG]] || Patient's Vital Signs ; Heart rate, Resp Rate, Pulse Ox, Temp, B/P, Pain || Including Pain Scale Assessment, Smoking Status ||
 * T.CC.23 || Review of Systems [[image:Check_mark.JPG]] || Functions of various body systems; Neuro, Derm, GI, GU, Cardiac, Pulmonary, MS, Repro, Nervous, Endocrine ||  ||
 * T.CC.24 || Hospital Course [[image:Check_mark.JPG]] || Sequence of (name, diagnosis associated with) events and dates from admission to discharge of hospital stay ||  ||
 * T.CC.25 || Diagnostic Results [[image:Check_mark.JPG]] || Results and dates of Diagnostic Procedures || Corresponding results to the scheduled procedures and interventions ||
 * T.CC.26 || Assessment and Plan || Assessment of patients conditions and expectations/goals of care ||  ||
 * T.CC.28 || Family History || Dates with Disease Suffered, Age of Death, other genetic information ||  ||
 * T.CC.29 || Social History || Patient's beliefs, home life, social/risky habits, family life, work history ||  ||
 * T.CC.30 || Encounters || Current and historical encounters; dates ||  ||
 * T.CC.31 || Medical Equipment - Medical Devices (C/N) - includes assistive devices and is related to functional status [[image:Check_mark.JPG]] || Implanted and External Medical Devices; Dates || * List of devices and where the device is to be secured/embedded.
 * Duration of medical devices.
 * History of devices (recalls, S/N, etc.). ||
 * T.CC.32 || Preoperative Diagnosis || Diagnosis (Date) assigned to patient previously to surgery ||  ||
 * T.CC.33 || Postoperative Diagnosis || Diagnosis (Date) assigned to patient after surgery ||  ||
 * T.CC.34 || Surgery Description || Particulars of Surgery (narrative) (images) ||  ||
 * T.CC.35 || Surgical Operation Note Findings || Clinically significant observations found during surgery ||  ||
 * T.CC.36 || Complications Section || Known risks or unidentified problems ||  ||
 * T.CC.37 || Operative Note Surgical Procedure || Date and Description of Procedure Performed ||  ||
 * [[image:Check_mark.JPG]] || Discharge Diet ||  || Part of Discharge Instructions ||
 * [[image:Check_mark.JPG]] || Functional Status ||  || Part of Discharge Instructions ||
 * [[image:Check_mark.JPG]] || Plan of Care ||  || Part of Discharge Instructions ||


 * Dataset for Clinical Summary:**

The User Stories Sub-Workgroup defined the following clinical summary content.


 * Clinical Summary including Consultation Request Summary**

Clinical Summary always includes //Core// basic dataset:
 * Demographic information, active medication list (with doses and sig), allergy list, problem list, reason for referral, etc.

Clinical Summary contains //variable// //dataset relevant to the context of the request//:

Examples: Substance intolerance Associated Adverse Events || List of allergies which might include allergy to what (e.g., medication. food, environment).
 * Cover note describing the clinical impetus for the referral
 * For a cardiologist consultation request: cardiology relevant tests and results such as Cardiac Echo results, Holter Monitor results, etc.; cardiology-pertinent family history, social histories, procedures, PE findings, etc..
 * For a dermatologist consultation request: dermatology relevant tests and results such as skin biopsy path report, image of lesion, dermatology pertinent family history, social histories, procedures, PE findings, etc..
 * Specific example:
 * PCP has worked up a patient who has a working diagnosis of Thyroid Cancer and is referring the patient to an Endocrine Surgeon.
 * Summary includes //standard//basic dataset as above as well as PCP-selected referral-specific variable dataset. E.g.:
 * //Pertinent PE finding and history of present illness//: 3 month history of a //2 cm R// //sided, hard thyroid nodule//
 * //Pertinent results and diagnosis:// FNA done 2/28/11 significant for medullary carcinoma, Calcitonin 2700, CEA 7, TSH, T3 Free T4 all normal
 * //Pertinent Additional Diagnoses Medical /Surgical Hx//: significant only for 3 year history of mild obesity, current BMI 30
 * //Pertinent Family History//: significant for Thyroid cancer mother (unknown type). No family history of MEN Syndromes. No family history of radiation exposure.
 * //PCP referral request and determination of responsibility:// Please evaluate for possible MEN II syndrome, surgery, post-operative care, and any special recommendations. I will assume full care status post the procedure.
 * //Reference to shared information with Patient:// I have reviewed all of the above information with the patient and his wife.
 * //Patient did/did not understand what was communicated//
 * **Ref. || Section || Content || Additional Notes ||
 * T.CC.1 || Personal Information || Name, DOB, Next of Kin, Address, Phone Number, Gender, Marital Status, Religion, Race, Ethnicity ||  ||
 * T.CC.2 || Contact Information || Contact Name, Contact Number ||  ||
 * T.CC.3 || Insurance Information || Insurance Name, Phone #, Group #, Type, Member #, Subscriber Name, Financial responsibility ||  ||
 * T.CC.4 || Healthcare Provider || Provider Name, Address, Phone Number, Type ||  ||
 * T.CC.5 || Allergies/Other Adverse Reactions || Allergy Type; and Date

Yes/No/Unknown, and if Yes or Unknown how does it affect care.

Other history that guide care

Patient supplied information about reaction || congenital problems || Current Diseases &
 * T.CC.6 || Problem List Active Problems (R/N)/Chief Complaint (overriding problem at the time of discharge) - chronic illness and

Conditions monitored for the patient and status || * List of problems/complaints (what was diagnosis, complaint and/or descriptor of problem/complaints, symptoms). Is a list, of diagnosis, complaints some of these may have been resolved and some are active.
 * How do these problems/complaints impact interventions, orders or instructions. Discharge instructions usually are for the encounter just ending.
 * Patient's perception or description of problems/complaints is usually in notes or history. Not part of a formal problem list. ||
 * T.CC.7 || History of Past Illness/Resolved Problems || Diseases & Conditions Patient has suffered in the past || May be a list with dates onset and/or resolution ||
 * T.CC.8 || Chief Complaint (see change in T.CC.6 Problem List) || Description of Patient's Complaint (narrative) || If not listed, in the problem list ||
 * T.CC.9 || Reason for Transfer || Reason Patient is being referred || May come from Utilization Review (UR) or Medicare rules, insurance or HMO rules or the patient may be well. ||
 * T.CC.10 || History of Present Illness || Sequence of events proceeding patient's disease/condition ||  ||
 * T.CC.11 || List of Surgeries || List of types of surgeries and dates ||  ||
 * T.CC.12 || Diagnosis || List of Hospital Diagnosis and dates || Current encounter list only ||
 * T.CC.13 || Medications || List of Current Medication Names ; date, route, dose, frequency || * List of prescribed medications or other medications. (Should be the reconciled list (which should have been done on admission)
 * If to be reconciled then list needs to be inclusive of self-administered medications (herbals, over the counter)
 * See notes on medication reconciliation regarding expectations such as discontinued medications from inpatient if not included in discharge summary
 * NOTES: Instructions may be more detailed if sent to another provider ||
 * T.CC.15 || Advance Directives || A summary of patient's expectations for care || * Yes/No, if Yes then date of
 * Yes/No if POLST form returned
 * Where is last known version/original is located
 * Going forward how the "state" and how it affects care ||
 * T.CC.16 || Pregnancy || Pregnant, Yes/NO ||  ||
 * T.CC.17 || Immunizations || Immunizations name, dose, route, date administered to the patient || Comprehensive list of immunizations (have - patient reported, got, need):* list of immunizations necessary to get after discharge.* list of education or information about immunizations they received while hospitalization ||
 * T.CC.18 || Physical Examination || Physical Findings of the Patient; VS, Biometrics, Review of Systems ||  ||
 * T.CC.19 || Vital Signs

Vital Signs (R/N) including Pain Scale Assessment, Smoking Status || Patient's Vital Signs ; Heart rate, Resp Rate, Pulse Ox, Temp, B/P, Pain || Instructions regarding the capture of vital signs at points along the care plan and any special instructions regarding how to capture || Plan of Treatment/Treatment Plan/Care Plan (R/N) - Covers the considerations that encompass a range of scopes and/or timeframe (could be a description of a single encounter or across multiple encounters || Proposed interventions and procedures for patient || * Goals.
 * T.CC.20 || Review of Systems || Functions of various body systems; Neuro, Derm, GI, GU, Cardiac, Pulmonary, MS, Repro, Nervous, Endocrine ||  ||
 * T.CC.21 || Diagnostic Results || Results and dates of Diagnostic Procedures || Corresponding results to the scheduled procedures and interventions. ||
 * T.CC.22 || Plan of Care
 * Results yet to be received and procedures to be followed up on.
 * Active interventions and orders (short term direct instructions - in the long run as validated by the patient and those contributed by the patient/caregiver). ||
 * || Education ||  ||   ||
 * || Diet/Diet Restrictions (R/N) ||  || Diet:

- All instructions that describe the ordered diet.

Restrictions:

- List of limitations being placed on the diet || - All instructions that describe the expected fluids and method of administration.
 * || Fluids Management (Conditional/No) ||  || Fluids:

Restrictions: - List of limitations being placed on fluids || Yes/No-has the plan been accepted by the patient, if no then how addressed || Duration of medical devices. History of devices (recalls/S/N, etc.) || Functional Status End state, Goal Expressed, Projected change in functional status (will relate to the goals identified) ||
 * ||  ||   || Yes/No-has the plan been reviewed with the patient?
 * T.CC.23 || Family History || Dates with Disease Suffered, Age of Death, other generic information ||  ||
 * T.CC.24 || Social History || Patient’s beliefs, home life, social/risky habits, family life, work history ||  ||
 * T.CC.25 || Encounters || Current and historical encounters; dates ||  ||
 * T.CC.26 || Medical Equipment-includes assistive devices and is related to functional status || Implanted and External Devices; dates || List of devices and where the device is to be secured/prescribed/embedded.
 * T.CC.27 || Preoperative Diagnosis || Diagnosis (date) assigned to patient previously to surgery ||  ||
 * T.CC.28 || Postoperative Diagnosis || Diagnosis (date) assigned to patient after surgery ||  ||
 * T.CC.29 || Surgery Description || Particulars of Surgery (narrative) (images) ||  ||
 * T.CC.30 || Surgical Operation Note Findings || Clinically significant observations found during surgery ||  ||
 * T.CC.31 || Complications Section || Known risks or unidentified problems ||  ||
 * T.CC.32 || Operative Note Surgical Procedure || Date and description of Procedure Performed ||  ||
 * T.CC.33 || Electronic Links ||  || How to get future results, summaries, etc ||
 * ADDED || Functional Status (Optional/No) ||  || Baseline, current and desired:
 * ADDED || Relevant Diagnostic Surgical Procedures/Clinical Reports and Relevant Diagnostic Test and Reports ||  ||   ||
 * ADDED || Patient Administrative Identifiers ||  ||   ||


 * Consultation Summary for specialist notes:**

Summary always includes //Core// dataset:
 * Demographic information, //specialist-reconciled// active medication list (with doses and sig when known), allergy list, //specialist-reconciled// problem list, specialist recommendations, etc.

Summary contains variable dataset relevant to the context of the referral:
 * Pertinent findings, test or study results, procedures or operations and reports, indication of any specialty ongoing follow up responsibilities, what has been communicated to the patient, patient’s level of understanding of what was communicated, etc.
 * **Ref. || Section || Content || Notes by Sub-Workgroup ||
 * T.CC.1 || Personal Information || Name, DOB, Next of Kin, Address, Phone Number, Gender, Marital Status, Religion, Race, Ethnicity ||  ||
 * T.CC.2 || Contact Information || Contact Name, Contact Number ||  ||
 * T.CC.3 || Insurance Information || Insurance Name, Phone #, Group #, Type, Member #, Subscriber Name, Financial responsibility ||  ||
 * T.CC.4 || Healthcare Provider || Provider Name, Address, Phone Number, Type ||  ||
 * T.CC.5 || Allergies and Other Adverse Reactions || Allergy Type; and Date || List of allergies which might include allergy to what (e.g., medication. food, environment) ||
 * ^  ||^   || Substance intolerance ||^   ||
 * ^  ||^   || Associated Adverse Events ||^   ||
 * ||  ||   || Yes/No/Unknown, and if Yes or Unknown how does it affect care. ||
 * ^  ||^   ||^   || Other history that guide care. ||
 * ^  ||^   ||^   || Patient supplied information about reaction ||
 * T.CC.6 || Problem List || Current Diseases || List of problems/complaints by patient to specialist and what was diagnosis, complaint and/or descriptor of problem/complaints, symptoms ||
 * ^  || Active Problems (R/N)/Chief Complaint (overriding problem at the time of discharge) - chronic illness and congenital problems || Conditions monitored for the patient and status || How do these problems/complaints impact interventions, orders or instructions. ||
 * ^  ||   ||   || Patient's perception or description of problems/complaints - was there discussion with patient? ||
 * T.CC.7 || History of Past Illness || Diseases & Conditions Patient has suffered in the past || Optional if relevant new discovery - resolved problems ||
 * T.CC.8 || Chief Complaint (see change in T.CC.6 Problem List) || Description of Patient's Complaint (narrative) || If patient tells specialist different complaint than was reported by PCP ||
 * T.CC.9 ||  || Reason Patient is being referred ||   ||
 * T.CC.10 || History of Present Illness || Sequence of events proceeding patient's disease/condition || If different or in addition to PCP history ||
 * T.CC.11 || List of Surgeries and Procedures || List of types of surgeries and procedures with date || If any performed by specialist ||
 * T.CC.14 || Medications || List of Current Medication Names ; date, route, dose, frequency || List of prescribed medications or medications administered by specialist ||
 * ^  ||^   ||^   || If to be reconciled then list needs to be inclusive of self-administered medications (herbals, over the counter) ||
 * T.CC.17 || Medications Administered || Medications administered to patient during the course of an encounter; name, dose, route, frequency || If relevant to referral ||
 * T.CC.18 || Advance Directives || A summary of patient's expectations for care || Yes/No (Optional in context of Consultation) ||
 * T.CC.19 || Pregnancy || Pregnant, Yes/NO || Only if relevant ||
 * T.CC.20 || Immunizations || Immunizations name, dose, route, date administered to the patient || Immunizations administered or recommended by specialist ||
 * T.CC.21 || Physical Examination || Physical Findings of the Patient; VS, Biometrics, Review of Systems || Pertinent positive or negative finding only ||
 * T.CC.22 || Vital Signs || Patient's Vital Signs ; Heart rate, Resp Rate, Pulse Ox, Temp, B/P, Pain || Pertinent positive or negative findings only ||
 * ^  || Vital Signs (R/N) including Pain Scale Assessment, Smoking Status ||^   ||^   ||
 * T.CC.23 || Review of Systems || Functions of various body systems; Neuro, Derm, GI, GU, Cardiac, Pulmonary, MS, Repro, Nervous, Endocrine || Pertinent positive or negative findings only ||
 * T.CC.25 || Diagnostic Results || Results and dates of Diagnostic Procedures || Corresponding results to the scheduled procedures and interventions. ||
 * T.CC.26 || Assessment and Plan || Assessment of patients conditions and expectations/goals of care || See Plan of Care in regards discussions with patient ||
 * T.CC.27 || Recommended Plan of Care

Plan of Treatment/Treatment Plan/Care Plan (R/N) - Covers the considerations that encompass a range of scopes and/or timeframe (could be a description of a single encounter or across multiple encounters || Proposed interventions and procedures || Goals. Details for follow-up, expectations, as needed.

Active interventions and orders (short term direct instructions - in the long run as validated by the patient and those contributed by the patient/caregiver). ||
 * ^  ||^   ||^   || Yes/No - has the specialist findings, recommendations and instruction been reviewed with the patient. ||
 * ^  ||^   ||^   || Yes/No - Have these instruction been accepted by the patient, if no then how addressed ||
 * ^  ||^   ||^   || Yes/No - Has patient been involved in formulation of plan of care ||
 * || Education || Patient education provided or needed. To include classes, educational sessions, and printed materials. || If relevant ||
 * || Fluids Management (Conditional/No) || All instructions that describe the expected fluids and method of administration. || If relevant ||
 * T.CC.28 || Family History || Dates with Disease Suffered, Age of Death, other genetic information || Optional if relevant ||
 * T.CC.29 || Social History || Patient's beliefs, home life, social/risky habits, family life, work history || Optional if relevant ||
 * T.CC.31 || Medical Equipment || Implanted and External Medical Devices; Dates || List of devices and where the device is to be secured/prescribed by specialist. ||
 * || Medical Devices (Conditional/No) - includes assistive devices and is related to functional status ||  || Optional if implanted or applied or with special instructions by specialist ||
 * ||  ||   || History of devices for this patient. ||
 * || Functional Status (Optional/No) -scales, scores || SHOULD be present when any assessments of functional status are performed on the patient || If relevant - Baseline, current and desired:* Functional status* End state/goal expressed/Projected change in functional status (will relate to the goals identified) ||
 * || Electronic Links || How to get to future results, summaries, etc. ||  ||

Appendix A: Related Use Cases

 * AHIC Consultations and Transfers of Care
 * AHIC Consumer Empowerment; Consumer Access to Clinical Information
 * AHIC Common Data Transport
 * AHIC Clinical Notes Detail
 * AHIC Personalized Healthcare
 * NHIN Direct Primary care provider refers patient to specialist including summary care record
 * NHIN Direct Primary care provider refers patient to hospital including summary care record
 * NHIN Direct Specialist sends summary care information back to referring provider
 * NHIN Direct Hospital sends discharge information to referring provider

Appendix B: Previous Work Efforts Related to Clinical Information Exchange

 * Health Information Technology Standards Panel Specification IS03: The Consumer Empowerment and Access to Clinical Information via Networks Interoperability Specification defines specific standards needed to assist patients in making decisions regarding care and healthy lifestyles (i.e., registration information, medication history, lab results, current and previous health conditions, allergies, summaries of healthcare encounters and diagnoses). This Interoperability Specification defines specific standards needed to enable the exchange of such data between patients and their caregivers via networks.
 * Health Information Technology Standards Panel Specification IS09: The Consultations and Transfers of Care Interoperability Specification describe the information flows, issues and system capabilities that apply to a provider requesting and a patient receiving a consultations from another provider.
 * HITSP Information Technology Standards Panel Specification C32: The Summary Documents Using HL7 Continuity of Care Document (CCD) Component describes the document content summarizing a consumer's medical status for the purpose of information exchange. The content may include administrative (e.g., registration, demographics, insurance, etc.) and clinical (problem list, medication list, allergies, test results, etc) information. This Component defines content in order to promote interoperability between participating systems such as Personal Health Record Systems (PHRs), Electronic Health Record Systems (EHRs), Practice Management Applications and others.
 * Health Information Technology Standards Panel Specification C83: The CDA Content Modules Component defines the content modules for document based HITSP constructs utilizing clinical information. These Content modules are based on IHE PCC Technical Framework Volume II, Release 4. That technical framework contains specifications for document sections that are consistent with all implementation guides for clinical documents currently selected for HITSP constructs. View the most current version as HTML
 * Health Information Technology Standards Panel Specification IS107: This Interoperability Specification consolidates all information exchanges and standards that involve an EHR System amongst the thirteen HITSP Interoperability Specifications in place as of the February 13, 2009 enactment of the American Recovery and Reinvestment Act (ARRA). This Interoperability Specification is organized as a set of HITSP Capabilities, with each Capability specifying a business service that an EHR system might address in one or more of the existing HITSP Interoperability Specifications (e.g., the Communicate Hospital Prescriptions Capability supports electronic prescribing for inpatient prescription orders)
 * Health Level 7: The CDA Release 2.0 provides an exchange model for clinical documents (such as discharge summaries and progress notes) - and brings the healthcare industry closer to the realization of an electronic medical record. By leveraging the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable - so they are easily parsed and processed electronically - and human-readable - so they can be easily retrieved and used by the people who need them. CDA documents can be displayed using XML-aware Web browsers or wireless applications such as cell phones. While Release 2.0 retains the simplicity of rendering and clear definition of clinical documents formulated in Release 1.0 (2000), it provides state-of-the-art interoperability for machine-readable coded semantics. The product of 5 years of improvements, CDA R2 body is based on the HL7 Clinical Statement model, is fully RIM-compliant and capable of driving decision support and other sophisticated applications, while retaining the simple rendering of legally-authenticated narrative.

Appendix C: Privacy and Security Assumptions
Security attributes includes capabilities needed to establish trust between systems, provide confidentiality while in-transit, ensure authenticity of the data, and ensure that only authorized individuals have access to the data.
 * **Feature** || **Feature Applicability** ||
 * Audit Logging || X ||
 * Authentication (Person) || X ||
 * Authentication (System) || X ||
 * Data Integrity Checking || X ||
 * Error Handling || X ||
 * HIPAA De-Identification || X ||
 * Holding Messages ||  ||
 * Non-repudiation || X ||
 * Pseudonymize and Re-Identify ||  ||
 * Secure Transport || X ||
 * Transmit Disambiguated Identities || X ||
 * User Login || X ||

Appendix D: Glossary
These items are included to clarify the intent of this use case. They should not be interpreted as approved terms or definitions but considered as contextual descriptions. There are parallel activities underway to develop specific terminology based on consensus throughout the industry.


 * Access Logs:** An integrated view of who has accessed the consumer/patient’s health information for the purposes of direct or indirect patient care.


 * Acute Care:** Treatment for a short period of time in which the patient is treated for a brief episode of illness. Acute Care is generally associated with care in a short term facility which is usually a non-emergency department setting.


 * AHIC:** American Health Information Community; a federal advisory body chartered in 2005, serving to make recommendations to the Secretary of the U.S. Department of Health and Human Services in regards to the development and adoption of health information technology.


 * Ancillary Entities:** Organizations that perform auxiliary roles in delivering healthcare services. They may include diagnostic and support services such as laboratories, imaging and radiology services, and pharmacies that support the delivery of healthcare services. These services may be delivered through hospitals or through free-standing entities.


 * Care Coordination:** Functions that help ensure that the patient’s needs and preferences for health services and information sharing across people, functions, and sites are met over time.


 * Care Coordinators:** Individuals who support clinicians in the management of health and disease conditions. These can include case managers and others.


 * Clinical Support Staff:** Individuals who support the workflow of clinicians.


 * Clinicians:** Healthcare providers with patient care responsibilities, including physicians, advanced practice nurses, physician assistants, nurses, psychologists, pharmacists, and other licensed and credentialed personnel involved in treating patients.


 * Consultation:** Meeting of two or more clinicians to evaluate the nature and progress of disease in a particular patient and to establish diagnosis, prognosis, and therapy.


 * Consumers:** Members of the public that include patients as well as caregivers, patient advocates, surrogates, family members, and other parties who may be acting for, or in support of, a patient receiving or potentially receiving healthcare services.


 * Electronic Health Record (EHR):** An electronic, cumulative record of information on an individual across more than one healthcare setting that is collected, managed, and consulted by professionals involved in the individual's health and care. This EHR description encompasses similar information maintained on patients within a single care setting (a.k.a., Electronic Medical Record (EMR)).


 * Electronic Health Record (EHR) System Suppliers:** Organizations which provide specific EHR solutions to clinicians and patients such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities.


 * Geographic Health Information Exchange/Regional Health Information Organizations:** A multi-stakeholder entity, which may be a free-standing organization (e.g., hospital, healthcare system, partnership organization) that supports health information exchange and enables the movement of health-related data within state, local, territorial, tribal, or jurisdictional participant groups. Activities supporting health information exchanges may also be provided by entities that are separate from geographic health information exchanges/Regional Health Information Organizations including integrated delivery networks, health record banks, and others.


 * Health Information Exchange (HIE**): An electronic network for exchanging health and patient information among healthcare delivery organizations, according to specific standards, protocols, and other agreed criteria. These functional capabilities may be provided fully or partially by a variety of organizations including free-standing or geographic health information exchanges (e.g., Regional Health Information Organizations (RHIOs)), integrated care delivery networks, provider organizations, health record banks, public health networks, specialty networks, and others supporting these capabilities. This term may also be used to describe the specific organizations that provide these capabilities such as RHIOs and Health Information Exchange Organizations.


 * Healthcare Payers:** Insurers, including health plans, self-insured employer plans, and third party administrators, providing healthcare benefits to enrolled members and reimbursing provider organizations.


 * HITSP:** The American National Standards Institute (ANSI) Healthcare Information Technology Standards Panel; a body created in 2005 in an effort to promote interoperability and harmonization of healthcare information technology through standards that would serve as a cooperative partnership between the public and private sectors.


 * Laboratories:** A laboratory (often abbreviated lab) is a setting where specimens are sent for testing and analysis are resulted, and then results are communicated back to the requestor. The types of laboratories may include clinical/medical, environmental, and veterinarian, and may be both private and/or public.


 * ONC:** Office of the National Coordinator for Health Information Technology; serves as the Secretary’s principal advisor on the development, application, and use of health information technology in an effort to improve the quality, safety, and efficiency of the nation's health through the development of an interoperable harmonized health information infrastructure.


 * Patients:** Members of the public who receive healthcare services. For hospice providers, the patient and family are considered a single unit of care. Synonyms used by various healthcare fields include client, resident, customer, patient and family unit, consumer, and healthcare consumer.


 * Personal Health Record:** A health record that is initiated and maintained by an individual. An ideal PHR would provide a complete and accurate summary of the health and medical history of an individual by gathering data from many sources and making this information accessible online to anyone who has the necessary electronic credentials to view the information.


 * Pharmacies:** Entities that exist that are experts on drug therapy and are the primary health professionals who optimize medication use to provide patients with positive health outcomes


 * Provider:** An individual clinician in a care delivery setting who requests or accepts the transfer of the clinical summary for the purposes of delivering care.


 * Provider Organizations**: Organizations that are engaged in or support the delivery of healthcare. These organizations could include hospitals, ambulatory clinics, long-term care facilities, community-based healthcare organizations, employers/occupational health programs, school health programs, dental clinics, psychology clinics, care delivery organizations, pharmacies, home health agencies, hospice care providers, and other healthcare facilities.


 * Registries:** Organized systems for the collection, storage, retrieval, analysis, and dissemination of information to support health needs. This also includes government agencies and professional associations which define, develop, and support registries. These may include emergency contact information/next of kin registries, patient registries, disease registries, etc.

Appendix E. References

 * American Health Information Community; AHIC; [|www.hhs.gov/healthit/healthnetwork/background]
 * The American National Standards Institute (ANSI) Healthcare Information Technology Standards Panel; HITSP; [|www.HITSP.org]
 * Health Level Seven; HL7; [|www.HL7.org]
 * Meaningful Use Final Rule; Dept of Health and Human Services; [|www.edocket.access.gpo.gov/2010/pdf/2010-17207.pdf]
 * Nationwide Health Information Network; NHIN; [|www.hhs.gov/healthit/healthnetwork/background]
 * The ONC-SI-UC-Simplification Spreadsheet (Current Version)
 * http://wiki.siframework.org/Cross+Initiative+-+Use+Case+Simplification+SWG

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