TRANSITION OF CARE (TOC)
PILOTS GUIDE
1. INTRODUCTION
The Transition of Care is one of the key initiatives 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.
The Transition of Care (ToC) Initiative addresses improvements in care coordination and patient
engagement in their own healthcare. 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. 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. This exchange is dependent on a secure,
interoperable environment.
The standardized patient clinical summary will provide timely, accurate, and structured information at
the point of care to the receiving provider. The accuracy of clinical information will help ensure that
clinicians provide high quality care. Defining the minimum data elements to be exchanged and mapping
them to MU-specified formats will better enable providers to use the specifications in a timely manner to
exchange the required clinical data between care settings.
2. PURPOSE OF THE GUIDE
The purpose of this ToC Pilots Guide is to provide ToC Pilot participants with the information required
to successfully plan and conduct a ToC pilot.
3. PURPOSE OF THE TOC PILOTS
The purpose of ToC Pilots is to verify the following, optionally using the ToC Reference
Implementation (RI) API,


ToC Implementation Guide (IG) validation.
Clinical information mapping and transformation for
o ToC Information Packets.
Last Updated 09/26/2011
Page 1 of 8
 Discharge Summary provides a synopsis of a patient’s admission to a
hospital and pertinent information for the continuation of care following
discharge.
 Consultation Request Clinical Summary provides a request for consultation,
and a core set of clinical and administrative information between clinicians,
as well as additional context specific information which may be provided to
and/or requested by the consulting clinician. Requesting clinicians can
transmit a core set of patient information and more.
 Consultation Summary provides information from provider organization
surrounding a consultation and consultation context-relevant data.
 Discharge Instructions provides procedures for going home from the
hospital and include follow-up/plan of care.
o Data Dictionary providing standardization of data elements.
o Vocabulary Mapping containing harmonized data elements.
4. PILOT CONFIGURATIONS
4.1.
MINIMUM CONFIGURATION
The Transition of Care Use Cases focuses primarily on the information which needs to be transmitted
between organizations. However, in order to implement a System which supports the S&I Transition of
Care Initiative, a fully operational system must be created.
Pilot participants will propose system configurations that, meet the following minimum requirements.





ToC Clinical Information sender, an Electronic Health Record (EHR) system.
ToC Clinical Information receiver, an Electronic Health Record (EHR) system or a Personal
Health Record (PHR) system.
A transport system or mechanism that is being used in Production environments.
A security system or mechanism that is being used in Production environments.
A means to capture and log
o Generated/Received messages
o Generated/Received acknowledgments
Each pilot participant can include system configurations in addition to the requirements listed above.
4.2.
ACTORS INVOLVED
A pilot may involve the following participants from the healthcare ecosystem:

EHR or PHR vendor

[Optional] Healthcare Information Services Provider (HISP) or System Integrator
Last Updated 09/26/2011
Page 2 of 8

Provider and/or Patient
The following diagram provides a sample pilot with configuration requirements divided by
participant’s likely responsibilities.
Provider or
Patient or
Caregiver etc.
Provider
HISP or System
Integrator
EHR Vendor
EHR
ToC
Reference
Library
API
Vendor
specific
adapter
Transport,
Security &
Other
EHR or PHR Vendor
Vendor
specific
adapter
ToC
Reference
Library
API
Figure 1. Pilot Flow and Functionality
Table 1 lists the Pilot User Functions for EHR vendor (as sender), HISP or System Integrator (to serve as
gateway connecting individual EHRs), and EHR or PHR vendor (as receiver).
Table 1. Pilot User Functions
EHR Vendor (as sender)
Configure EHR
Integrate with ToC RI API
Integrate appropriate adapter
Create Messages
Publish Message
Last Updated 09/26/2011
HISP or System Integrator
Create approach to capturing
transmitted and received messages
Facilitate Communication/
Collaboration between sender and
receiver vendors
Integration
Create Transport Mechanism
Create Security Mechanism
EHR or PHR Vendor (as receiver)
Configure EHR or PHR
Integrate with ToC RI API
Integrate appropriate adapter
Receive Messages
Parse, store message contents
Page 3 of 8
EHR
or
PHR
4.3.
USE CASE
[From ToC Use Case document at – ToC Use Case & Requirements (UCR) WG]
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
through a HISP.
2. The ability of the Personal Health Record to send and/or receive Clinical Information through a
HISP.
Figure 2: Use Case Diagram
Last Updated 09/26/2011
Page 4 of 8
Send Clinical Summary, Consultation
Request Summary Discharge Summary
and/or Discharge Instruction
est
qu
Re arge
n
io isch
tat
su l / o r D
n
o
, C and
ary ary
m
m
m m ns
o
l Su Su
ica arge tructi
n
i
l
h
s
C
c
n
I
Patient
ves Dis
cei ry,
)
Re ma
pe
Sco
Sum
f
o
ut
s (O
R
H
rE
ide
v
o
Pr
tes
da
p
U
Transition Of Care
Provider_1
Receive Clinical Summary and
Consultation Summary
Re Rece
qu ive
est
C
Sum linic
a
or mar l Sum
Dis y D m
cha isc ary
rge har , Co
Ins ge S nsu
tru um lta
ctio ma tion
ns ry a
Sen
nd
dC
/
lini
cal
Sum
Sum mar
ma y an
dC
ry
on
su l
t
Provider_2
Figure 3: Context Diagram
Scenario 1: The Exchange of Clinical Summaries from Provider to Provider
Scenario 2: The Exchange of Clinical Summaries between Provider to Patient in support of ToC
User Stories of Scenario 1
User Story 1: The Exchange of Information to Support the Transfer of Patient Information from One
Provider to Another
Setting 1: Hospital or Emergency Department from where patient is discharged (sends discharge
summary to PCP or Care Team).
Setting 2: Patient's PCP or Care Team (receives discharge summary from Hospital or ED clinical system).
Last Updated 09/26/2011
Page 5 of 8
User Story 2: Closed Loop Referral
Setting 1: PCP's office (sends consultation request clinical summary to specialist).
Setting 2: Specialist's office (receives referral request clinical summary from PCP; send consultation
summary to PCP).
Return to Setting 1: PCP’s office
User Story 3: Complex Series of Care Transactions
Setting: Emergency Department
Setting: Hospital
Setting: Rehabilitation Facility
User Stories of Scenario 2
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.
Setting 1: Hospital or ED from where patient is discharged (sends discharge instructions to patient).
Setting 2: Patient
User Story 2: The Exchange of Clinical Summaries between Provider and Patients to Support the Closedloop Transfer of a Patient from One Care Setting to Another Consultation Referral.
Setting 1: PCP’s office
Setting 2: Specialist’s office
Setting 3: Patient
5. SUCCESS CRITERIA

Successfully create and transmit messages that comply with ToC artifacts. Optionally
utilize and integrate an EHR system with ToC RI API.

Conformance to ToC Implementation Guide (IG)

Use ToC Artifacts
 CIM/Vocabulary
 ToC Implementation Guide (IG)
 Toc RI API
Last Updated 09/26/2011
Page 6 of 8

Utilize and integrate an EHR or PHR system with ToC RI API to successfully receive the
message contents that were sent from the sender.

Provide feedback for improving the ToC artifacts.
6. SCHEDULE
Pilots may participate in IHE Connectathon and/or HIMSS Showcase. Participation in the HIMSS
Showcase is encouraged.
Table 2 lists the scheduled milestones affecting ToC Pilots through February 2012.
Table 2. Scheduled Milestones
Date
October 18-19, 2011
January 9-13, 2012
February 21-23, 2012
Event
F2F meeting (Washington D.C.)
Connectathon (Chicago, IL)
HIMSS Showcase (Las Vegas, NV)*
* participants provide their own schedule
7. RESPONSIBILITIES
7.1.
ONC

Promote pilots’ success

Receive and assess feedback

Define overall success metrics

Gather lessons learned

Facilitating and coordination
7.2.
TOC PILOTS WORKGROUP

Outreach

Provide ongoing education, support, and training to pilot participants

Provide specifications (Artifacts)
1. CIM/Vocabulary
2. ToC Implementation Guide (IG)
3. Toc RI API
4. ToC RI integration support
Last Updated 09/26/2011
Page 7 of 8

Provide Project Management for the ToC Pilots
1. Pilot project guidance (this document)
2. Review, evaluate and approve proposed pilots
3. Monitor pilot progress and receive/report status
4. Evaluate test results
7.3.
PILOT PARTICIPANTS

Complete the pilot application and deployment

Conduct successful test according to provided test plan (or equivalent)

Provide results to S&I Framework Pilots Workgroup for evaluation

Provide in-process progress information
8. IHE CONNECTATHON AND HIMSS
It is not mandatory to participate in the IHE Connectathon. The ONC pilot support team will be
coordinating readiness review sessions with pilots to ensure they are prepared to showcase at HIMSS.
Date
September 30, 2011
January 9-13, 2012
•
Date
October 8, 2011
February 21-23, 2012
Last Updated 09/26/2011
IHE Connectathon 2012
Event
Registration deadline
Connectathon (Chicago, IL)
HIMSS12 Interoperability Showcase
Event
Registration deadline (extension for ONC pilots only)
HIMSS Showcase (Las Vegas, NV)*
* participants provide their own schedule
Page 8 of 8