Ushering in a new era of data standardization across Health IT, Project US@ (“Project USA”) Technical Specification Final Version 1.0 was released on January 7, 2022. This project has been a year-long effort to bring standardization to patient address information exchanged between care teams who capture information and healthcare IT systems, to improve patient matching.
Audacious Inquiry’s David Pyke, an interoperability subject matter expert, lent his expertise in helping the Office of the National Coordinator for Health Information Technology (ONC) roll out the final standards. The resulting 65-page document outlines standardized formats for street names, pre- and post-directionals, special characters, and accepted short forms for street types for personal, business, and military addresses.
We asked David to give us the “Cliff’s Notes.”
How Did Project US@ Get Its Start?
The Project US@ Technical Specification started from the US Postal Service’s Publication 28, which sets the standards for addresses for postal mail but allows more variability and has fewer absolute requirements. The technical team started from this publication and adapted learnings to electronic health records (EHRs). The goal of the Project US@ Technical Specification is to improve patient matching between healthcare IT systems by removing the variability in addresses exchanged between systems to better allow for the receiving system to match the received address with the one on file. Aspects like capitalization, short forms, punctuation, and non-continental U.S. addresses were discussed and restricted to ensure the data sent would be of the best possible quality for patient matching.
Why is Project US@ Important for Patient Matching?
For a practitioner to have a complete record of a patient’s care outside of that practitioner’s organization, the information received by an EHR needs to be matched on demographics such as name and address. Names can be variable (e.g., McDonald vs MacDonald), adding complexity to the ability to merge the records together. By limiting the variability of address data, that one aspect can be used more effectively to ensure that the data is merged with the right patient. For example:
12 E Main Lane, #209
This address can be written many ways. The street can be both “E” or “East” Main, and the word “apartment” can be written out or abbreviated as “APT” or include only the unit numbers as in “#209” or “209-12.” All these ways make it more complex to determine where that patient lives and if it’s a match for the patient record in the EHR.
By making the records consistent via capitalizing all letters, removing all punctuation, and making sure only the street name and city are spelled out, we can be sure that the confusion that a receiving system sees is minimized, as in:
209-12 E MAIN LN
KNOXVILLE TN 38188-0002
This format, when adhered to by exchanging systems, can improve patient matching throughout the healthcare system. For example, if a notification is sent out from a hospital that a patient, Jane Gomez, living at the address above has been admitted, a standard formatted address means no guesswork has to be done to match it with the Jane Gomez in the notification forwarding system, living at that address.
If the address is formatted to the requirements of the Project US@ Technical Specification both in the outgoing notification and in the notification system, Jane Gomez’s admission can be more accurately forwarded to this patient’s Primary Care Physician (PCP). When received by the PCP’s EHR, the notification can be easily merged into the EHR record by matching to Jane Gomez’s record in that EHR. Subsequently, the PCP will quickly learn that their patient needed admission and can begin the process to review her record and schedule follow-ups or additional out-of-hospital care on discharge.
Most people do not think about the format of addresses. Human beings can look at most addresses and make the intuitive leap from what is on the screen to a point on a map. However, a system that has received a poorly formatted address can make mistakes, leading to mismatched or orphaned data that may impede proper patient care.
Audacious Inquiry encourages care teams to get the newly published standard, its companion guide, and the friendly “The Importance of Patient Address” high-level infographic, and start the process of working with their patient data to conform to the specification. This can be done in the patient record itself, or as a service attached to interoperability systems that formats data to match the specification.
David Pyke has been working with Healthcare IT in the EMEA, USA, and other regions providing technical design, strategic advice, and training for organizations and governments, for over 15 years. David is a subject matter expert in HIEs and health IT standards including FHIR, privacy, and security. He is a co-chair and member of technical workgroups for healthcare IT standards development organizations including IHE and HL7.
As an active member of HL7 International, David is a member of the Technical Steering Committee, a Project Lead on the FHIR Consent Resource project and co-chair of the Community-Based Care and Privacy Workgroup. David is a trainer on FHIR and FHIR implementation guide creation, the lead author of the TEFCA QHIN Technical Framework, and author of public and private FHIR Implementation Guides.