FHIR/HL7 Standards Integration — Vendor-Neutral Healthcare Commerce Connectivity

HealthSail operates as a full FHIR R4 participant — functioning as both a FHIR client that consumes resources from external FHIR servers and a FHIR server that exposes commerce data as FHIR resources. As a FHIR client, HealthSail queries external FHIR endpoints for Patient, Coverage, ServiceRequest, Encounter, and Practitioner resources, using the data to populate commerce customer records, verify insurance eligibility, and initiate clinical-context-aware commerce workflows. As a FHIR server, HealthSail exposes commerce orders as ServiceRequest resources, fulfillment status as Task resources, and payment records as PaymentNotice resources — enabling external systems (EHRs, care coordination platforms, billing systems) to query HealthSail commerce data through standard FHIR APIs without custom integration. The FHIR server implementation supports FHIR search parameters, pagination, and the _include and _revinclude operations that enable external systems to retrieve related resources in a single query. FHIR Subscription resources are supported for event-driven notifications when commerce data changes — for example, notifying the EHR when an order status changes from processing to shipped.

HealthSail supports the SMART on FHIR application launch framework, enabling HealthSail commerce workflows to be launched from within EHR interfaces that support SMART app integration. When a provider or patient launches HealthSail from within an EHR, the SMART launch protocol passes the current patient context, user identity, and authorization scope through a secure OAuth 2.0 flow. HealthSail receives the patient context, resolves the patient to a HealthSail customer record, and presents the appropriate commerce experience — product catalog, ordering interface, or account portal — without requiring the user to re-authenticate or manually identify the patient. The SMART launch implementation supports both EHR launch (initiated from within the EHR) and standalone launch (initiated from outside the EHR with subsequent patient selection), and complies with the SMART App Launch Implementation Guide version 2.0. This embedded launch model is the preferred integration pattern for Epic and Cerner deployments where provider workflow interruption must be minimized and patient context must be passed securely between the clinical and commerce systems.

For healthcare organizations with established HL7v2 interface infrastructure, HealthSail provides a standards-compliant HL7v2 message processing engine that handles inbound and outbound message flows across the ADT, ORM, OMP, DFT, and SIU message types commonly used in healthcare operations. Inbound ADT messages (Admit, Discharge, Transfer) trigger patient demographic updates in HealthSail customer records, ensuring that address changes, insurance updates, and admission/discharge events are reflected in the commerce system. Inbound ORM messages can initiate commerce ordering workflows when orders originate from clinical systems. Outbound ORM/OMP messages deliver commerce order data to fulfillment or pharmacy systems that accept orders via HL7v2 interfaces. Outbound DFT messages post financial transaction data from commerce payments to billing systems. The HL7v2 engine supports both MLLP (Minimal Lower Layer Protocol) over TCP and secure transport options including TLS-wrapped MLLP and HTTPS-based message delivery. Message acknowledgment (ACK/NAK) processing ensures reliable message delivery with configurable retry logic for failed transmissions.

Healthcare organizations rarely operate a single-vendor IT environment. A typical health system may use Epic for inpatient care, athenahealth for ambulatory practices, a separate pharmacy system, a distinct billing platform, and multiple departmental applications — each with different integration capabilities. HealthSail's standards-based integration layer provides a consistent connectivity model across this heterogeneous landscape. Rather than building and maintaining separate vendor-specific integrations for each system, the organization can route patient data, orders, and financial transactions through FHIR and HL7v2 interfaces that are system-agnostic. The standards layer also provides forward compatibility: as healthcare organizations migrate between systems — a common occurrence during mergers, acquisitions, and platform consolidation — the standards-based integration continues to operate as long as the replacement system supports the same FHIR or HL7v2 interfaces. This reduces the integration rework that typically accompanies healthcare IT transitions and protects the organization's investment in commerce infrastructure from being tied to a specific clinical system vendor.