Physical place of available services or resources.

Data Element
Facility GPS Coordinates
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).
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.
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 1 - Data element is captured, stored, or accessed in at least one production EHR or HIT module.
Criterion #3
Maturity - Current Exchange		 Level 1 - Data element is electronically exchanged between two production EHRs or other HIT modules using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.
Evaluation Comment While technical specification for the data element is available, use of those specifications for data exchange in production environments is limited.

Comment

Log in or register to post comments