HL7 & FHIR Interoperability

I map payer/provider workflows onto the Da Vinci trio CMS points at: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). The CMS-0057-F fact sheet puts operational PA rules generally in 2026 and the FHIR APIs generally on 1 January 2027. A technical walkthrough is at /insights/da-vinci-prior-authorization-fhir.

There is no single FHIR profile set. AU Core, EU Core/EHDS, US Core/TEFCA, UK Core, and ISiK each constrain identifiers, must-support elements, and search differently. Start from the market you sell into, then map Patient and Encounter before expanding. A concrete AU Core R2 and AU eRequesting walkthrough is at /insights/fhir-au-core-implementation; country comparisons live under /insights/fhir-implementation-guides-by-country.

HL7v2 is a message-based standard from the 1990s that uses pipe-delimited text messages sent over TCP connections. It excels at real-time, event-driven data exchange and is deeply embedded in existing healthcare infrastructure. FHIR (Fast Healthcare Interoperability Resources) is a modern RESTful API standard that uses JSON or XML and leverages familiar web technologies. FHIR is designed for broader use cases including mobile apps, patient access, and cloud-based services. Both standards coexist in modern healthcare environments and will continue to do so for years.

C-CDA (Consolidated Clinical Document Architecture) is a standard for structured clinical documents. It is used primarily for transitions of care, such as when a patient is discharged from a hospital and their summary needs to be sent to their primary care provider. C-CDA documents include sections for problems, medications, allergies, procedures, lab results, and vital signs. They are required by Meaningful Use regulations and are exchanged through health information exchanges and direct messaging.

HL7v2 is intentionally flexible, which means every sending system implements it slightly differently. I address this by building robust parsers that handle optional segments gracefully, mapping Z-segments (custom extensions) for each trading partner, and implementing comprehensive validation that catches data quality issues before they propagate. I maintain transformation libraries that account for the most common variations across major EHR vendors.

US Core is a FHIR Implementation Guide that defines the minimum set of FHIR resources, profiles, and search parameters that EHR systems in the United States must support. It is mandated by the ONC and forms the foundation of the 21st Century Cures Act interoperability requirements. If you are building a FHIR-based application that will work with US healthcare data, conforming to US Core profiles ensures compatibility with the broadest range of EHR systems.

Yes. The Trusted Exchange Framework and Common Agreement (TEFCA) is establishing a national framework for health information exchange. I help organizations understand the technical requirements of TEFCA participation, implement the required FHIR interfaces, and prepare for connectivity through Qualified Health Information Networks. This includes ensuring your FHIR implementation conforms to the TEFCA-specified profiles and security requirements.

I use the official FHIR Validator for resource validation, HAPI FHIR for Java-based FHIR server development, and custom Node.js/TypeScript libraries for FHIR client development. For testing, I use Inferno for US Core conformance testing, Touchstone for interoperability testing, and Postman collections for API endpoint validation. I also build automated test suites that verify FHIR conformance as part of the CI/CD pipeline.