Open Transaction Rails
Paving the way for the vertically-integrated, patient-centric transaction
The current electronic transaction standard in healthcare follows an Electronic Data Interchange (EDI) format first established in the 1960s, a national standards organization (ANSI) established in the 1970s, and a healthcare-specific standard established through the ASC X12N committee that took root in the early 1980s. The Health Insurance Portability and Accountability Act of 1996 codified the ASC X12 EDI standards as a required digital format for communicating healthcare financial information.
The ASC X12 standard forms the foundation of millions of healthcare financial data exchanges in the US every day. In spite of this, we’ve long outgrown this decades-old, proprietary set of standards. The elimination of administrative burden in the United States requires a path towards a new, open transaction standard that is cross-compatible and backwards compatible with the EDI-backed system we use today.
In addition to the adoption of a new Financial Module standard, we support a shift in governance to enforce strict adherence to the standard instead of private, bespoke customization as seen in the industry today. In the banking industry, this shift occurred through the establishment of the Federal Reserve. In healthcare, this SSO may emerge through either private, public, or governmental oversight. In doing so, we would eliminate the administrative cost of transmitting and processing transaction data that currently powers large, private clearinghouse businesses in the United States.
Limitations of the current ASC X12 EDI standard
1. It’s proprietary.
The ASC X12 Standard requires a license to access. Without open access to standards and standards enforcement, we see the emergence of heterogeneity in the form of Companion Guides that list payer-specific modifications of the ASC X12 standards. Here are a few examples:
The continued existence of Companion Guides is evidence of the inefficiency and heterogeneity of healthcare transaction standards. If the system moves towards standard modular contracts and a common payment system, it then becomes possible to create and enforce adherence to a single open financial transaction messaging standard.
2. It’s not patient-facing.One of the most common complaints from patients is that they don’t know how much they owe. It’s vital that patients have one source of truth ledger for balances and bills (vs. dealing with out-of-date EOBs, mail that doesn’t match online portals, bills that have not yet been processed by insurance, cash pay claims vs. insured claims, and even dealing with secondary insurance or lapses in insurance).
We’d be introducing a way for these transactions to make it to the patient via third-party apps for the first time. Patients can opt in to these apps in the same way they opt in to sharing their clinical data per the 21st Century CURES Act. The apps used by patients to book their appointments and receive their prescriptions are already based on open FHIR standards, so this is a natural progression for the industry.
3. It lacks the basic benefits of modern technology, gatekeeping innovation.Healthcare billing data is exchanged in ASC X12 file formats that require dense manuals to interpret. Software developers have to be trained on these archaic, proprietary file formats. Learning to interpret them feels like learning to decipher ancient hieroglyphics.
Data exchange systems in nearly every other industry are now built on simple, self-describing data formats like JSON or XML. These newer formats are easily understood by any software developer, leading to faster innovation. Healthcare billing, despite being conceptually similar to financial transactions in any other industry, gatekeeps innovation by hiding behind hard-to-interpret, proprietary data formats.
For example, a software developer in the FinTech space can quickly leverage APIs provided by a multitude of established and emerging companies to build innovative solutions, leading to Americans being able to trade stocks, bonds, and options instantly, right from their phones. Meanwhile, healthcare software developers are struggling to decipher arcane X12 files to access the most basic patient information, like whether 2300/DTP01=434 signals that the patient’s discharge date is the same as their insurance coverage date or if that rule only applies when 2300/DTP02=RD8.
We’ve already seen how adopting modern data exchange formats has impacted other aspects of healthcare. The open FHIR data standards have been widely adopted for sharing basic patient visit information between providers and patient apps. Now most patients have access to apps that let them see their upcoming appointments, view diagnosis results and prescribed drugs, and access their basic healthcare data. But the amount of data shared is very limited in scope and patients still have no access to billing information via these apps. By replacing X12 data formats with open, accessible, industry-standard FHIR data formats, the same innovation will be possible for transparent patient billing.
Proposed solution
We propose replacing legacy ASC X12 transaction communications with the modern, open replacements proposed by the FHIR project’s Financial Module. Each legacy X12 transaction (checking patient eligibility, submitting a claim, receiving a payment, etc) has a direct FHIR replacement.
These are the mappings between each legacy X12 transaction type and the modern replacement:
FHIR is a fully open standard that can be implemented by anyone. Any software vendor is able to implement any piece of the healthcare transaction without payment or licensing to a third party. FHIR standards have already proven themselves in the clinical side of healthcare by enabling direct patient access to provider diagnostics and prescriptions. FHIR standards are widely supported within healthcare outside of billing, so this is the lowest-friction and most pragmatic solution.
Documentation for the FHIR Finance Module is available for free, but many software developers are not interested in working with the raw data and are seeking to quickly implement specific features in their application. For any software developer that wishes to implement any part of the FHIR financial standards themselves, Turquoise Health will provide an open source toolkit with examples of each transaction type in Q2 2025 published on our Github page. This will make it easy for any software developer to start from a common sense recipe of how to implement basic transactions, like checking a patient’s insurance coverage, filing a claim, or making a payment.
We also expect vendors to implement simple frontends for these standards, much as we see in the FinTech industry. Turquoise Health will offer a hosted platform that supports the full healthcare billing cycle based on these standards to make it easy for providers, payers, and other parties to quickly interface with the payment systems of healthcare. We expect that other companies will offer similar services, such as clearinghouses, TPAs, and other health tech companies. The open FHIR standards allow any interested companies to do this without paying licensing fees or requiring permission.
Acknowledgements
Changing the underpinnings of healthcare payments is a thorny topic with many industry councils, government, and private companies involved. Moving to simple, standardized billing standards requires pragmatic solutions and the ability for different parties to transition on different timelines.
Industry has a role to play by providing software systems that can interoperate between older and newer systems, allowing for different parties to migrate at different times.
Government has a role to play in sponsoring the move to a new system. Use of the legacy X12 system billing is required by HIPAA, so regulation changes need to be made to allow for using newer systems like FHIR.
PATIENTS seeks to stand on the shoulders of the best existing open working concepts, much of which has been created through the DaVinci HL7 work group and FHIR. Our intent is to release a FHIR compatible module for “most common use cases” for initial industry adoption and feedback in Q2.
We have no opinion on whether Clearinghouses of the future will be private, non-profit, or government-run entities - just that true immutable standards should emerge using modern technology with a patient-exposed interface.