CMS Data Element Library (DEL)

1a. Project Name Centers for Medicare and Medicaid Services (CMS) Data Element Library (DEL) 1b. Project ID 1565 1c. Is Your Project an Investigative Project (aka PSS-Lite)? No 1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU? No 1e. Today's Date 1f. Name of standard being reaffirmed 1g. Project Artifact Information 1h. ISO/IEC Standard to Adopt 1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption? 1j. Unit of Measure 2a. Primary/Sponsor WG Patient Empowerment 2d. Project Facilitator Dave Hill 2e. Other Interested Parties (and roles) Office of the National Coordinator (ONC) 2f. Modeling Facilitator Tim Shaffer 2g. Publishing Facilitator Hibah Qudsi 2h. Vocabulary Facilitator Siama Rizvi 2i. Domain Expert Representative Sean Mahoney 2j. Business Requirements Analyst Sean Mahoney 2k. Conformance Facilitator Tim Shaffer 2l. Other Facilitators 2m. Implementers Sean Mahoney, Tim Shaffer, Jake O'Donnell, Dave Hill 3a. Project Scope Poor quality discharge information is a major barrier to safe and effective transitions. With 45% of Medicare beneficiaries requiring post-acute care (PAC) services after hospitalization, the need for a seamless exchange of health information is great. In 2014, the Social Security Act was amended to include the Improving Medicare Post-Acute Care Transformation (IMPACT) Act, which required the standardization and interoperability of patient assessment in specific categories for post-acute care (PAC) settings, including long-term care hospitals (LTCHs), home health agencies (HHAs), skilled nursing facilities (SNFs), and inpatient rehabilitation facilities (IRFs). It focuses on standardizing data elements in specified quality measure domains and patient assessment domains for cross setting comparison and clinical information exchange, respectively. The Act requires: • Reporting of standardized patient assessment data through commonly used PAC assessment instruments for LTCHs, SNFs, HHAs, and IRFs o Minimum Data Set (MDS)for SNFs o Inpatient Rehabilitation Facility – Patient Assessment Information (IRF – PAI) for IRFs o LTCH Continuity Assessment Record and Evaluation (CARE) Data Set (LCDS) for LTCHs o Outcome and Assessment Information Set (OASIS) for HHAs • Implementation of data elements specified in each assessment domain using standardized data elements to be nested within the assessment instruments currently required for submission by LTCH, IRF, SNF, and HHA providers • Data to be standardized and interoperable to allow exchange of data between PAC providers, among others, using common standards and definitions to provide access to longitudinal information and facilitate coordinated care. The CMS Data Element Library (DEL) supports IMPACT Act requirements by serving as the centralized repository for CMS PAC assessment data elements and their associated health information technology (IT) standards to promote interoperability of patient data. Required assessment content includes standardized questions and response options (aka “data elements”) for assessing a patient’s functional status, cognitive function/mental status, special services/treatments/interventions, medical conditions/co-morbidities and impairments. The mission of the Data Element Library (DEL) is to create a comprehensive, electronic, distributable, and centralized resource of CMS assessment instrument content. In support of the IMPACT Act, the goals of the DEL are to: • Serve as a centralized resource for CMS assessment data elements (questions and response options) • Promote the sharing of electronic CMS assessment data sets and health information technology standards; and • Influence and support industry efforts to promote Electronic Health Record (EHR) and other health IT interoperability PAC providers are required to submit data for all patients at admission and discharge , using PAC assessments, to the CMS Quality Improvement and Evaluation System (QIES) Assessment Submission and Processing (ASAP) system. This data is used for quality measurement, payment, survey and certification, public reporting, and other CMS and provider activities. Furthermore, because providers are required to submit this data to CMS for all patients at both admission and discharge, it can be reused and exchanged during care transitions to inform patient care. Attachments 3b. Project Need Despite the development of the DEL, interoperability challenges persist; providers are not receiving complete and accurate information in a timely manner, leading to patient harm. Failure to exchange accurate, timely data often leads to inefficient workflows, duplicative data entries, and increased risk of patient harm attributable to missing or inaccurate information. Health IT can significantly alleviate this administrative burden by incorporating PAC assessments and DEL content into electronic health records (EHRs) to facilitate health data exchange and therefore improved patient outcomes, reduced provider burden, improved cost efficiencies, and improved workflows. Moreover, it would allow for advanced computability, standardization, usability, and real-time analytics of the DEL via FHIR interfaces for PAC facilities, enabling broader use by health IT developers, researchers, providers, and payers. As the PAC assessments are updated on a regular basis, a DEL FHIR API could ensure EHRs had access to the most current data sets. Starting in FY 2018, MITRE developed prototype source definitions for a set of FHIR profiles that describe how to use FHIR to convey the DEL patient assessment information defined by the IMPACT Act. The proof-of-concept prototype demonstrated that the DEL patient assessment information could be fully described by a generated FHIR Implementation Guide (IG), through FHIR profiles and extensions, which will allow Health IT implementers easy access to the information to the DEL. Further work is underway to provide a complete IG and reference implementation for DEL resources and data. The success of the reference implementation could inform future efforts defining FHIR IGs for all PAC data that would also harmonize with other interoperability initiatives across the healthcare spectrum, including acute and ambulatory care. 3c. Security Risk No 3d. External Drivers None 3e. Objectives/Deliverables and Target Dates Project Scope Statement Due: 2019 Aug 16 FHIR IG Proposals Due: 2019 Nov 3 Notice of Intent to Ballot: 2019 Nov 17 FHIR Ballot Core Substantive Freeze: 2019 Nov 29 Initial Content Deadline: 2019 Dec 1 Reconciliation Deadline and Ballot Preview Period: 2019 Dec 8 Final Content Deadline: 2019 Dec 22 Ballot Readiness Sign Off: 2019 Dec 27-28 Ballot Open for Voting: 2019 Dec 27 – 2020 Jan 27 3f. Common Names / Keywords / Aliases: PAC Assessments 1) Resident Assessment Instrument (RAI) Minimum Data Set (MDS) used by Skilled Nursing Facilities (SNFs) 2) Inpatient Rehabilitation Facility – Patient Assessment Information (IRF-PAI) used by IRFs 3) LTCH Continuity Assessment Record and Evaluation (CARE) Data Set (LCDS) used by Long-Term Care Hospital (LTCHs) 4) Outcome and Assessment Information Set used by Home Health Agencies (HHAs) 3g. Lineage N/A 3h. Project Dependencies To be determined 3i. HL7-Managed Project Document Repository URL: https://github.com/paciowg/del 3j. Backwards Compatibility No 3k. Additional Backwards Compatibility Information (if applicable) 3l. Using Current V3 Data Types? N/A 3l. Reason for not using current V3 data types? 3m. External Vocabularies Yes 3n. List of Vocabularies LOINC, SNOMED 3o. Earliest prior release and/or version to which the compatibility applies N/A 4a. Products FHIR Implementation Guide, FHIR Profiles, FHIR Resources, Guidance (e.g. Companion Guide, Cookbook, etc) 4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to? FHIR version R4 4c. FHIR Profiles Version FHIR version R4 4d. Please define your New Product Definition 4d. Please define your New Product Family 5a. Project Intent Create new standard 5a. White Paper Type 5a. Is the project adopting/endorsing an externally developed IG? 5a. Externally developed IG is to be (select one) 5a. Specify external organization 5a. Revising Current Standard Info 5b. Project Ballot Type Comment (aka Comment-Only) 5c. Additional Ballot Info 5d. Joint Copyright No 5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval. no 6a. External Project Collaboration Center for Medicare and Medicaid Services (CMS), Office of the National Coordinator (ONC), Post-Acute Care Interoperability (PACIO) Project 6b. Content Already Developed 80% 6c. Content externally developed? Yes 6d. List Developers of Externally Developed Content 6e. Is this a hosted (externally funded) project? Yes 6f. Stakeholders Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs) 6f. Other Stakeholders 6g. Vendors EHR, PHR, Health Care IT 6g. Other Vendors 6h. Providers Healthcare Institutions (hospitals, long term care, home care, mental health) 6h. Other Providers 6i. Realm U.S. Realm Specific 7d. US Realm Approval Date 7a. Management Group(s) to Review PSS FHIR 7b. Sponsoring WG Approval Date 7c. Co-Sponsor Approval Date 7c. Co-Sponsor 2 Approval Date 7c. Co-Sponsor 3 Approval Date 7c. Co-Sponsor 4 Approval Date 7c. Co-Sponsor 5 Approval Date 7c. Co-Sponsor 6 Approval Date 7c. Co-Sponsor 7 Approval Date 7c. Co-Sponsor 8 Approval Date 7c. Co-Sponsor 9 Approval Date 7c. Co-Sponsor 10 Approval Date 7e. CDA MG Approval Date 7f. FMG Approval Date 7g. V2 MG Approval Date 7h. Architecture Review Board Approval Date 7i. Steering Division Approval Date 7j. TSC Approval Date