Physical place of available services or resources.

Data Element
Facility Address
Submitted By: Keith W. Boone / Audacious Inquiry
Data Element Information
Rationale for Separate Consideration Patient Address is similar, but not the same as Facility Address. Facility Address should have at least the same constraints.
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).
Link to use case project page https://bit.ly/SANERBUILD
Healthcare Aims
  • Improving the health of populations
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Various:

FHIR DSTU2, 3 and 4, CDA Release 2.0, HL7 V2 PL Data Type
https://bit.ly/FHIRLocation
Additional Specifications V3.1.0: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-location.html
V3.0.0: http://hl7.org/fhir/us/core/2019Sep/StructureDefinition-us-core-location.html
V2.1.0: http://hl7.org/fhir/us/core/2019Jan/StructureDefinition-us-core-location.html
V2.0.0: http://hl7.org/fhir/us/core/STU2/StructureDefinition-us-core-location.html
Current Use Extensively used in production environments
Supporting Artifacts Widely available within EHR Systems, but not necessarily searchable.
https://open.epic.com/Interface/FHIR#Location
https://mydata.athenahealth.com/static/apidoc/ig-ge-location.html
https://fhir.cerner.com/millennium/r4/encounters/encounter/ (Reference to a Location resource)
https://developer.allscripts.com/FHIR?PageTitle=Resources
https://api.evident.com/dstu2/encounter (Location as an embedded resource)
https://www.questdiagnostics.com/dms/Documents/care360/Terms-Conditions/Quanum_EHR_FHIR_API.pdf (Quest only supports Location name in Immunizations)
https://bit.ly/USCore31
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts See US Core Connectathon report out: https://drive.google.com/file/d/1WNYWLEf28j8DPyDachC8jpk-QbkyuPxP/view

https://bit.ly/2DTBheD
Potential Challenges
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.

Comment

Submitted by BLampkins_CSTE on

CSTE Comment - v5

CSTE agrees with CDC's recommendation for this data element. 

Submitted by nedragarrett_CDC on

CDC's Comment for draft USCDI v5

CDC supports the inclusion of this data element in USCDI v5 as it is an element that may be necessary for calculation of our digital quality metrics from FHIR data.

Submitted by yale-coredQMRoadmap on

CDC and CMS-CCSQ Joint Support for Facility Address

Thank you for opportunity to comment on this data element. The Centers for Medicare and Medicaid Services (CMS) and the Centers for Disease Control and Prevention (CDC) emphasize the importance of patient safety being reflected in the USCDI standards. Identifying facility information, such as Facility Address, is critical to differentiate specific service locations and link data/records for public health and healthcare purposes. CMS and CDC strongly recommend the Facility Address data element (Level 2) in the Facility Information data class be added to USCDI. This addition would promote patient safety.

Submitted by yale-coredQMRoadmap on

CMS-CCSQ Support for Facility Address for USCDI v5

CMS-CCSQ recommends this Level 2 data element be added to USCDI v5. Together with the Facility Identifier, Facility Type, and Facility Name, the Facility Address data element will supplement the core set of information necessary to identify facilities and link service and outcome data to a specific physical institution or facility. This was previously identified as a joint CMS-CDC priority. Currently, in the absence of a unique Organization/Hospital Identifier in the USCDI, it can be difficult to differentiate specific service locations and link data or records for public health and healthcare purposes. Location information is routinely captured in EHR systems. Since Facility Names and Facility Identifiers (e.g., CCNs) can be shared by separately located facilities, Facility Address can provide critical identifying information to differentiate specific locations and accurately link data to optimally track care quality and health outcomes.

Submitted by nedragarrett_CDC on

CDC's Consolidated Comment for USCDI v5

  • The facility address is required in both Laboratory Domain and public health. In the laboratory domain, the test ordering facility address needs to be included in the data as required by the CLIA Regulation §493.1241(c)(1). The address of the test-performing laboratory is also required as indicated by the CLIA regulation §493.1291(c)(2). Test ordering facility is also an “R” or a required field in public health profiles in both Laboratory Orders Interface (LOI) and Laboratory Results Interface (LRI). We recommend inclusion of this element USCDI V5
  • NAACCR comment: For cancer registry (and other public health) reporting, facility address is required to determine the jurisdiction with authority to collect and report the test and results.
  • CSTE Comment: CSTE agrees with CDC's recommendation for this data element. 
  • NACCHO Comment: Supports CDC's comment.

Submitted by yale-coredQMRoadmap on

CMS-CCSQ/CDC Joint USCDIv4 Priority: Facility Address

Together with the Facility Identifier, Name and Type, the Facility Address data element will supplement the core set of information necessary to identify facilities and link service and outcome data to a specific physical institution or facility. Currently, in the absence of a unique Organization/Hospital Identifier in the USCDI it can be difficult to differentiate specific service locations and link data or records for public health and healthcare purposes, such as monitoring hospital capacity and respiratory disease burden in acute care hospitals, identifying and responding to outbreaks in facilities, and tracking patient safety events. Accurate facility information, including name, address, and identifier, is essential to analyze facility level data and inform the allocation of resources such as therapeutics, supplies, staffing, and PPE to prepare for and respond to emergency events.

Submitted by nedragarrett_CDC on

Unified Comment from CDC

  • CDC considers this element to be high priority and strongly recommends its inclusion in the USCDI V3
     
  • 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.

Log in or register to post comments