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. |
|
Submitted by nedragarrett_CDC on
CDC's Comment for draft USCDI v6
CDC has recommended inclusion of this field since USCDIv4 supporting a number of applications.
Facility address is an important piece of information for deaths, births and fetal deaths that occur in health care settings and are reported via an EHR, so support for a facility address data element as a core element would be beneficial.
Deaths in Hospital:
The place of death for in-hospital deaths may be provided by a funeral director or the medical certifier. Since medical certifiers may document place of death, it would be useful to have facility information as a core data element within the medical certifier’s EHR.
Births and Fetal Deaths in Healthcare Settings:
Most births and fetal deaths occur in a hospital or other health care facilities like birthing centers or clinic/doctor’s offices. When the mother or infant are transferred to another facility, the address of that facility also needs to be recorded.
Sources: U.S. STANDARD CERTIFICATE OF DEATH -- REV. 11/2003; Physician’s Handbook on Medical Certification of Death; Facility Worksheet for the Live Birth Certificate
Additionally, 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 strongly support including this element USCDI V6.
Furthermore, CDC is requesting an Organization/Hospital Identifier data element be included as part of Facility Address. Explanation to request an Organizational Identifier.
The National Health Care Surveys includes two separate surveys: National Hospital Care Survey and National Ambulatory Medical Care Survey (NAMCS)
Facility Identifier: National Hospital Care Surveys would benefit from a Facility Identifier because they sample at the hospital level (i.e. the hospital from the sampled location is the only site of interest) and it is associated with the physical place of available services or resources.
The recommendation differs for NAMCS Health Center Component who samples at the health center level (i.e. every subsidiary care delivery site under the sampled health center is sampled along with the health center). For that reason:
Facility Managing Organization Identifier: NAMCS Health Center Component samples all care delivery sites under the sampled health center. To increase NAMCS quality control it would be helpful to receive Facility Managing Organization Identifier, as it is associated with health care provider locations and ambulatory providers.