Description (*Please confirm or update this field for the new USCDI version*)
Sequence of characters representing a physical place of available services or resources.
Submitted By: Keith W. Boone
/ Audacious Inquiry
Data Element Information
Use Case Description(s)
Use Case Description
Facility level data is associated with laboratory tests (the testing facility), and health care provider locations, including hospitals, ambulatory providers, long-term and post acute care, and pharmacy providers.
Location data is used to support reporting of data for public health and emergency response (e.g., situation awareness reporting).
See https://build.fhir.org/ig/HL7/fhir-saner/ for details (note that (minus) - is a legal character in URLs, had to use a bit.ly link to get past validation errors in URL)
Estimate the breadth of applicability of the use case(s) for this data element
Hospitals in the US (Approximately 7000), Laboratories (260,000), pharmacies (88,000), ambulatory physicians (260,000).
5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Restrictions on Standardization (e.g. proprietary code)
None
Restrictions on Use (e.g. licensing, user fees)
None
Privacy and Security Concerns
Locations associated with Critical Access Hospitals, and single provider facilities may constitute PHI (in geographic locations with limited populations) and/or Individual Identifiable Information (e.g., for HCPs working from a combined home/office facility).
Estimate of Overall Burden
Most electronic systems provide the capacity to store location and organization information. Many EHRs already provide access to the Location resource via READ operations, some (e.g., Epic, AthentaHealth) provide search capabilities as well. This information is routinely communicated in HL7 V2 Messages, CDA Documents and some FHIR API transactions. To address gaps, implementers would need to modify interfaces (e.g., for CDA or HL7 V2), or add an endpoint. Estimated effort (based on past experience building EHR systems) is about one two-week sprint to implement the capability by a developer.
Other Implementation Challenges
Standards for location identifier may need flexibility depending on use of Location for reportiong, as there are a number of distinct location identifier systems which may be necessary for different reporting use cases. For example, CDC/NHSN assigns identifiers for HAI reporting, CLIA assigns identifiers to laboratories, CMS provides location identifiers, et cetera.
Identifiers are critical for billing, linking billing/clinical EHRs, supporting data aggregation across data sources and reducing burden, as well as attribution and tracking of data. All of these activities are necessary for providing high quality care to patients, reducing disparities, promoting interoperability and communicating across silos. Facility identifiers are also critical for public health reporting and tracking, an ONC stated priority for USCDI version 3.
CMS specifically prioritizes exchange of CMS Certification number (CCN), Provider Transaction number (PTAN), and National Provider Identifier (NPI)—unique identifiers for a healthcare organization.
Current uses, exchange, and use cases: CCN, PTAN, and NPI are exchanged across the nation for CMS reporting to appropriately attribute outcomes and measure results. Exchange of these identifiers supports facility-specific quality, prior authorization activities, and other assessments that are limited without this information.
General Comment: This comment supports the promotion of the Data Class Patient Demographics - Data Element Identifier to USCDI V3 as well as the additional Data Element of Identifier System, including the allowance of multiple instances of Identifier/ Identifier System pairs per patient (approach 1). We believe that this will allow needed flexibility to accommodate use and exchange of the variety of patient identifiers in current use in the US. An example of this approaches is: Identifier: 333224444, Identifier System: http://hl7.org/fhir/sid/us-ssn.
If ONC does not choose to incorporate approach 1, (Identifier + Identifier System), in USCDI V3, we recommend allowing for the following Patient Demographic Data Class Data Elements in USCDI V3: Medicare Patient Identifier, Medical Record Number and Social Security Number. (approach 2) We believe that allowing for both approaches would be confusing, so we recommend choosing one or the other.
Additional Use Case: This is a standard data (FIN or NPI) item used by central cancer registries in all states according to the North American Association of Central Cancer Registries (NAACCR) standard. Data received through data exchange from medical facilities (e.g., laboratories, hospitals, physician EHRs, etc.) to central cancer registries for CDC and NCI’s national cancer surveillance systems, as required by law.
CSTE supports inclusion of this measure into USCDI v3: Very useful for this information to be captured in some way and then subsequently used in reporting to PH.
Submitted by sg999 on
CMS-CCSQ Support for Facility/Organization Identifier: USCDIv3
Identifiers are critical for billing, linking billing/clinical EHRs, supporting data aggregation across data sources and reducing burden, as well as attribution and tracking of data. All of these activities are necessary for providing high quality care to patients, reducing disparities, promoting interoperability and communicating across silos. Facility identifiers are also critical for public health reporting and tracking, an ONC stated priority for USCDI version 3.
CMS specifically prioritizes exchange of CMS Certification number (CCN), Provider Transaction number (PTAN), and National Provider Identifier (NPI)—unique identifiers for a healthcare organization.
Maturity: