Skip to end of metadata
Go to start of metadata

1a. Project Name

Centers for Medicare and Medicaid Services (CMS) Data Element Library (DEL)

1b. Project ID


1c. Is Your Project an Investigative Project (aka PSS-Lite)?


1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?


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.


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


3d. External Drivers


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


3h. Project Dependencies

To be determined

3i. HL7-Managed Project Document Repository URL:

3j. Backwards Compatibility


3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?


3l. Reason for not using current V3 data types?

3m. External Vocabularies


3n. List of Vocabularies


3o. Earliest prior release and/or version to which the compatibility applies


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


5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.


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


6c. Content externally developed?


6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?


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


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