ToC+Document+Recommendations

include component="page" wikiName="siframework" page="TOC Header" =Transitions of Care Document Recommendations= Reference materials to inform this work are available here.

1. ToC Document Recommendations Activity
This wiki page facilitates the "Goodness of Fit" assessment of Consolidated CDA (C-CDA) documents, which can be used to fulfill Meaningful Use Stage 2 (MU2) exchange requirements at a minimum, and to fulfill ToC clinical scenarios. This activity expands on the initial MU2 analysis work to align MU2 requirements with Consolidated CDA documents and assesses the "goodness of fit" of Consolidated CDA documents to provide a best practice recommendation for the MU2 exchange and the ToC requirements in the ToC Companion Guide.

2. Consolidated CDA and MU2 Requirements
The ONC Standards and Certification 2014 Edition NPRM specifies Consolidated CDA as the standard to be sent between providers upon Transitions of Care, which it defines: //"Any EP, EH, or CAH who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide summary care record for each transition of care or referral."// It also specifies the mandatory data that must be included, which is largely the same, but has some variations between ambulatory and hospital settings. For more information on these assertions, please reference the ToC MU2 Analysis.

Consolidated CDA contains a large library of section and entry level templates that can be assembled in various ways to meet the requirements of MU2. It also contains several predefined structured document types -- Continuity of Care Document (CCD), Consultation Note, Diagnostic Imaging Report, Discharge Summary, History and Physical Note, Operative Note, Procedure Note, and Progress Note -- defined in sections 3.1 through 3.8. Each of these document types includes in its definition some, but not all, C-CDA sections. **None of the document types contains 100% of the data required for MU2, but all of them can be supplemented by other sections beyond the doctype definition to be included, so the documents can be made MU2-conformant.** This section of the Companion Guide provides guidance to help developers conform using a variety of document types, all conforming to C-CDA document-level, section-level, and entry-level templates.


 * Note on "transition of care" definition**: not every encounter produces a “Transition of Care.” Examples: routine patient appointment to PCP for flu shot; annual physical; minor illness such as cold/cough. In many cases, the patient is assessed and may be given a treatment such as a prescription and some instructions, goes home and recovers, and no ToC to another care setting occurs. For MU, a summary of care record is not //required// to be sent in those cases. CMS writes in its Meaningful Use Incentive Program NPRM: //“Currently, the meaningful use measures that use transitions of care require there to be a receiving provider of care to accept the information. Therefore, a transition home without any expectation of follow-up care related to the care given in the prior setting by another provider is not a transition of care for purpose of Stage 2 meaningful use measures as there is no provider recipient. ”// However, any of these encounters could “turn into” a ToC depending on what is discovered and what follow-up care is indicated (including referrals, hospitalizations, etc.).


 * Note on patient engagement.** While not every encounter produces a transition of care, MU2 requires that data be made electronically to the patient after every visit or hospitalization. So even if a "ToC" summary of care record is not produced or sent after every encounter, it is necessary to have information available for patients to "view, download, and transmit" after each encounter, and that information (essentially identical to the ToC SOCR) must also be made available electronically using C-CDA.

3. MU2 Summary of Care Record Content Requirements from the ONC NPRM, 170.314(b)(2)
The “Summary of Care Record” (SOCR) is described in ONC's Standards and Certification NPRM. The SOCR must be created as part of the Transitions of Care objective. //(i) Enable a user to electronically create a summary care record formatted according to the standard adopted at § 170.205(a)(3) and that includes, at a minimum, the following data elements expressed, where applicable, according to the specified standard(s): // //(A) Patient name; gender; date of birth; medication allergies; vital signs; laboratory tests and values/results; the referring or transitioning provider’s name and contact information; names and contact information of any additional care team members beyond the referring or transitioning provider and the receiving provider; care plan, including goals and instructions; // //(B) Race and ethnicity. The standard specified in § 170.207(f); // //(C) Preferred language. The standard specified in § 170.207(j); // //(D) Smoking status. The standard specified in § 170.207(1); // //(E) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3); // //(F) Encounter diagnoses. The standard specified in § 170.207(m); // //(G) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3); // //(H) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g); // //(I) Laboratory value(s)/result(s). The value(s)/results of the laboratory test(s) performed; // //(J) Medications. At a minimum, the version of the standard specified in § 170.207(h); and // //(K) Inpatient setting only. Hospital admission and discharge dates and location; names of providers of care during hospitalizations; discharge instructions; and reason(s) for hospitalization.//

4.1 Basic: Minimum Essential Requirements
The ONC NPRM does not specify any particular document type to contain the data mentioned above. It is possible to create a document that contains all MU2 data and nothing more, even if it does not conform to any of the predefined C-CDA document types, and such a document could meet MU2 requirements. That does not imply that this document is what every EHR should generate, or what clinicians will find useful. It is a statement of the **minimum essential** MU2 requirements.

This portion of the guidance describes a simple way to fulfill the minimum essential MU2 requirements. Other portions of the guidance will describe ways to fulfill additional requirements such as those of C-CDA predefined document types, and/or the requirements of the ToC clinical scenarios described elsewhere.

The spreadsheet (look first at the **MU2-CCDA Mapping tab**) illustrates a simple way to provide the SOCR. The table contains the ONC/CMS NPRM wording of data requirements on the left, with the corresponding C-CDA sections and entries on the right. The far right column contains notes that explains alternative ways to meet the MU2 requirement for data that can be expressed in multiple sections. See the table for further details regarding structured entries, vocabularies, etc. A simple “minimal essential” document can use the following sections to contain the MU2-required data: > this would contain “current and active diagnoses” including encounter diagnoses (contingent upon encounter diagnoses using the Problem List vocabulary (SNOMED-CT); currently the ONC NPRM proposes ICD-10 instead of SNOMED-CT, but CMS has proposed delaying ICD-10 1 year) > Chief Complaint and Reason for Visit can be used for to handle either ambulatory reason for visit or hospital reason for hospitalization Please not that these sections are not the ONLY way to satisfy MU in a simple way. The spreadsheet color coding shows where alternatives exist to provide the same MU2 data. For example, at least three sections (Reason for Visit, Chief Complaint, and Chief Complaint and Reason for Visit) can satisfy the "Reason for Hospitalization" and/or "Reason for Visit" MU2 requirements.
 * US Realm CDA Header
 * Social History Section with structured entry: Smoking History observation
 * Vital signs Section
 * Medications Section (entries required)
 * Allergies Section
 * Problem Section (entries required) –
 * Procedures Section (entries required)
 * Results Section (entries required)
 * Reason for Visit, **Chief Complaint and Reason for Visit**, or Chief Complaint Section
 * Immunizations Section (entries required)
 * Hospital Discharge Instructions Section (EH) or Instructions Section (EP)
 * Plan of Care Section

4.2 More Advanced: Meets MU2 and Conforms to Consolidated CDA Document Types
This section of the guidance addresses how to both meet MU2 and also conform to specific C-CDA document types. The guiding principle is to provide flexibility to use document types that are fit for the purpose of the hospital or provider. Examples (non-exhaustive and non-prescriptive):
 * In a closed loop referral, the consulting physician may wish to fulfill MU2 but also send back extensive additional information beyond the MU2 minimum. The C-CDA Consultation Note or CCD may provide a good "base document type" that can accomplish this, given inclusion of some additional MU2 data.
 * When a patient is discharged from a hospital, the hospital may wish to support the transition of care back to the admitting physician or PCP, while also fulfilling Joint Commission requirements. The C-CDA Discharge Summary or CCD may be good base document types to accomplish this.
 * When a patient undergoes a routine History and Physical with a PCP, conditions are discovered that require a referral to a specialist. The PCP wishes to document the History and Physical and also fulfill MU2 transition of care requirement when referring to the patient to a specialist. The C-CDA History and Physical may be a good base document type to accomplish this.
 * A network of providers may be connected to a local, regional, or state HIE that aggregates patient summary records from all sources using a CCD common summary record format. Some HIEs receive CCDs from providers and hospitals, and aggregate the data into a patient-centered record.

4.3 MU2 "Goodness of Fit" of Consolidated CDA Document Types
Analysis of the C-CDA document types vs. the MU2 requirements indicates that the **CCD** is the closest match to the requirements for both EP and EH.
 * For EP, CCD matched MU2 more closely than the Consult Note or the History and Physical, primarily due to the carryover from MU1 to MU2 of the requirements for **structured entries** in Medications, Allergies, Problems, Procedures, and Results sections, which are required in CCD but not in the other document types.
 * For EH, CCD matched MU2 //slightly// more closely than the Discharge Summary, but the differences are very narrow. CCD scored higher due to the carryover from MU1 to MU2 of the requirements for structured entries in Medications, Allergies, Problems, Procedures, and Results sections, which are not required in the Discharge Summary. On the other hand, Discharge Summary did better in certain areas because it requires certain MU sections that are not in CCD, such as Discharge Instructions, History of Past Illness, and Reason for Visit (Hospitalization).
 * Caveat: the above conclusion assumes that //only// MU2-required data is included in the document. Other document types' goodness of fit may improve depending on which additional data (beyond MU2) the provider wishes to transmit on a transition.

In the following descriptions of document types, only the sections **required** for MU2, or the sections **required** by the document type, are discussed. Other C-CDA sections may optionally be added to suit hospital and provider needs. If a document type requires data that are not required by MU and the data are not available, a nullFlavor can be used at the section level. For more guidance on how to do this, see the **Null Section Example** at the bottom of this Wiki page (which may be moved when the entire Companion Guide is assembled).

__**4.3.1 CCD document type**__
//**Eligible** **Hospital** **or Eligible Professional**// A C-CDA CCD document type that also conforms to MU2 for EH must include the following sections. The i//talicized sections marked with an asterisk// are C-CDA sections that are not included in the CCD document type definition, but must be included to meet MU2. Use of CCD is a straightforward evolutionary step for EHRs that already support CCD. CCD requires no sections that MU2 does not require, but it would need to contain some additional sections. > this would contain “current and active diagnoses” including encounter diagnoses > // can be used for either ambulatory reason for visit or hospital reason for hospitalization //
 * US Realm CDA Header (add encompassingEncounter encounter for encounter-specific providers, locations, and times)
 * Social History Section with structured entry: Smoking History observation
 * Vital signs Section
 * Medications Section (entries required)
 * Allergies Section
 * Problem Section (entries required) –
 * Procedures Section (entries required)
 * Results Section (entries required)
 * Immunizations Section (entries required)
 * Plan of Care Section
 * // * Reason for Visit Section OR Chief Complaint Section OR Chief Complaint and Reason for Visit Section //
 * // * Hospital Discharge Instructions (EH) or Instructions (EP) //

Sections **required** by this document type but not required for MU. These must be either valued or expressed as nullFlavor at the section level. >
 * None

__**4.3.2 Discharge Summary document type**__
//**Eligible** **Hospital** **only**// A C-CDA Discharge Summary document type that also conforms to MU2 for EH must include the following sections. The // italicized sections marked with an asterisk // are C-CDA sections that are not included in the Discharge Summary document type definition, but must be included to meet MU2. Discharge Summary is a good fit for the hospital discharge transition of care use case, though meeting Joint Commission requirements //and// providing the document within 36 hours of discharge (as MU2 requires for the document being available to the patient) can be challenging.
 * US Realm CDA Header(add documentationOf/serviceEvent for care providers outside encounter)
 * Social History Section with structured entry: Smoking History observation
 * Vital signs Section
 * Hospital Admission Medications Section (entries required) and/or Hospital Discharge Medications Section (entries required)
 * Allergies Section
 * Problem Section (entries required) OR [Hospital Admission Diagnosis Section and/or Hospital Discharge Diagnosis section]
 * Procedures Section (entries required)
 * Immunizations Section (entries required)
 * Plan of Care Section
 * Reason for Visit Section OR Chief Complaint Section OR Chief Complaint and Reason for Visit Section
 * Hospital Discharge Instructions
 * // * Results Section (entries required) //

Sections **required** by this document type but not required for MU. These must be either valued or expressed as nullFlavor at the section level. >
 * Hospital Course Section

__**4.3.3 Consultation Note document type**__
A C-CDA Consultation Note document type that also conforms to MU2 for EP must include the following sections. The // italicized sections marked with an asterisk // are C-CDA sections that are not included in the Consultation Note document type definition, but must be included to meet MU2. Consultation Note is a good fit for the "closed loop referral" transition of care use case, specifically the send part of the "loop" where the specialist reports his/her findings to the referring physician.
 * Eligible Professional Only**
 * US Realm CDA Header (add documentationOf/serviceEvent for care providers outside encounter)
 * Social History Section with structured entry: Smoking History observation
 * Vital Signs Section
 * Medications Section (entries required)
 * Allergies Section
 * Problem Section (entries required)
 * Procedures Section (entries required)
 * Results Section (entries required)
 * Reason for Visit section
 * Immunizations Section (entries required)
 * Plan of Care Section OR Assessments and Plan Section
 * // * Instructions section //

Sections **required** by this document type but not required for MU. These must be either valued or expressed as nullFlavor at the section level.
 * Physical Exam Section
 * History of Present Illness Section

**__4.3.4 History and Physical document type__**
A C-CDA History and Physical document type that also conforms to MU2 for EP must include the following sections. The // italicized sections marked with an asterisk // are C-CDA sections that are not included in the H&P document type definition, but must be included to meet MU2. H&P may be a good fit for visits where history and physical were performed, and a follow-up by a different provider was recommended (therefore resulting in a transition of care). > this would contain “current and active diagnoses” including encounter diagnoses Sections **required** by this document type but not required for MU. These must be either valued or expressed as nullFlavor at the section level
 * US Realm CDA Header (add documentationOf/serviceEvent for care providers outside encounter)
 * Social History Section with structured entry: Smoking History observation
 * Vital signs Section
 * Medications Section (entries required)
 * Allergies Section
 * Problem Section (entries required) –
 * Procedures Section (entries required)
 * Results Section (entries required)
 * Reason for Visit Section
 * Immunizations Section (entries required)
 * Plan of Care Section OR Assessments and Plan Section
 * // * Instructions section //
 * Family History Section
 * History of Past Illness Section
 * History of Present Illness Section
 * Review of Systems Section
 * Physical Exam Section
 * General Status Section

__**4.3.5 Additional Document Types**__
The same principles used in mapping MU2 requirements to the document types above can be used for the additional C-CDA document types. However, the results of the analysis shows that the other C-CDA document types (Diagnostic Imaging Report, Operative Note, Procedure Note, and Progress Note) are significantly farther away from meeting MU2 requirements than the CCD, Consultation Note, Discharge Summary, and History and Physical mapped above. They do not contain many of the sections required for MU2, and they also require many sections that are not required for MU2. This is visually apparent by looking at the **Crosswalk** tab and seeing the degree to which the cells in columns G-J do not match the cells in columns M, N, P, Q, and R.

5. Meeting MU2, C-CDA Document Types, AND ToC Clinical Scenarios
In the analysis of ToC requirements below, the same principles described in "Meeting MU2 Requirements using Consolidated CDA Sections" were applied. See the EP and EH tabs in the Requirements Mapping spreadsheet for details. The Goodness of Fit for each clinical scenario is assessed below.

//5.1.1 Referral from PCP to Specialist (1st part of "loop")//
In addition to the data required for MU2 (see section 4.1 and following), ToC recommends the data shown in column E of the **EP** tab in the Requirements Mapping spreadsheet. The details of data elements are not practical to show on this Wiki page. The spreadsheet explains which C-CDA sections are recommended to meet **both MU2 and ToC closed loop referral scenarios.** Column N-S of that tab include "scoring for goodness of fit" of three C-CDA document types that were logical candidates to satisfy the MU2 and ToC requirements. The results of the scoring: For a different view of the extent to which ToC recommends more data than MU2, see the **CCDA to MU2 & ToC** tab in the Requirements Mapping spreadsheet. Column D shows the requirements for ToC PCP to Specialist, with color coding indicating the differences, which is explained in Column Q.
 * The **Continuity of Care Document (CCD) is the best fit for the PCP to Specialist (referral) document.** In every cell in Column N that has a "0" score, CCD does not contain that C-CDA section in its definition, but the section can still be added to the CCD to "fill in the gaps" and meet the MU2 and/or ToC requirements. CCD's higher score was due to the same reasons why it scored higher for MU2: the requirement for structured data in many sections, which matched the ToC requirements for much structured data.
 * The **Consult Note** is the second best fit for the Referral.
 * The **History and Physical** is a less good fit, but can still be made to work.

//5.1.2 Report from Specialist to PCP (2nd part of "loop")//
In addition to the data required for MU2 (see section 4.1 and following), ToC recommends the data shown in column F of the **EP** tab in the Requirements Mapping spreadsheet. The details of data elements are not practical to show on this Wiki page. The spreadsheet explains which C-CDA sections are recommended to meet **both MU2 and ToC closed loop referral scenarios.** Column N-S of that tab include "scoring for goodness of fit" of three C-CDA document types that were logical candidates to satisfy the MU2 and ToC requirements. The results of the scoring: For a different view of the extent to which ToC recommends more data than MU2, see the **CCDA to MU2 & ToC** tab in the Requirements Mapping spreadsheet. Column E shows the requirements for ToC Specialist to PCP, with color coding indicating the differences, which is explained in Column Q.
 * The **Continuity of Care Document (CCD) is the best fit for the Specialist to PCP (consult) document.** In every cell in Column N that has a "0" score, CCD does not contain that C-CDA section in its definition, but the section can still be added to the CCD to "fill in the gaps" and meet the MU2 and/or ToC requirements.
 * The **Consult Note** is the second best fit for the Consult.
 * The **History and Physical** is a less good fit, but can still be made to work.

5.2 Discharge from Hospital
In addition to the data required for MU2 (see section 4.1 and following), ToC recommends the data shown in column D of the **EH** tab in the Requirements Mapping spreadsheet. The details of data elements are not practical to show on this Wiki page. The spreadsheet explains which C-CDA sections are recommended to meet **both MU2 and the ToC Discharge scenario.** Column L-M of that tab include "scoring for goodness of fit" of two C-CDA document types that were logical candidates to satisfy the MU2 and ToC requirements. The results of the scoring: For a different view of the extent to which ToC recommends more data than MU2, see the **CCDA to MU2 & ToC** tab in the Requirements Mapping spreadsheet. Column F shows the requirements for ToC Hospital Discharge, with color coding indicating the differences, which is explained in Column Q.
 * The **Discharge Summary is the best fit for the discharge document.** In every cell in Column N that has a "0" score, Discharge Summary does not contain that C-CDA section in its definition, but the section can still be added to "fill in the gaps" and meet the MU2 and/or ToC requirements.
 * The **Continuity of Care Document** is the second best fit for the Discharge.
 * No other documents were close to meeting both the ToC and MU2 requirements.

Miscellaneous Notes
None at this time.

Null Section Example
The following example shows how to express a nullFlavor at a CDA section level, rather than at a data element level. Hospital Course is used in this example, but the same principle can be applied for other sections    <templateId <span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> root <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"1.3.6.1.4.1.19376.1.5.3.1.3.5" <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;">/> <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"><code <span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> code <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"8648-8" <span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> displayName <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"HOSPITAL COURSE" <span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> codeSystem <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"2.16.840.1.113883.6.1" <span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> codeSystemName <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"LOINC" **<span style="color: #f5844c; font-family: 'Times New Roman','serif'; font-size: 16px;"> nullFlavor <span style="color: #ff8040; font-family: 'Times New Roman','serif'; font-size: 16px;">= <span style="color: #993300; font-family: 'Times New Roman','serif'; font-size: 16px;">"NI" **<span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;">/> <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"> <span style="color: #000000; font-family: 'Times New Roman','serif'; font-size: 16px;">HOSPITAL COURSE <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"> <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"> <span style="color: #000000; font-family: 'Times New Roman','serif'; font-size: 16px;"> The hospital course was not documented yet <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"> <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;"> <span style="color: #000096; font-family: 'Times New Roman','serif'; font-size: 16px;">

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