Elixir
Request a Demo
  • Electronic Health Record (EHR)Products
  • Revenue Cycle ManagementProducts
  • Eligibility VerificationProducts › Revenue Cycle Management
  • Electronic Prior AuthorizationProducts › Revenue Cycle Management
  • Denial ManagementProducts › Revenue Cycle Management
  • Professional and Institutional Claim PreparationProducts › Revenue Cycle Management
  • Electronic Visit VerificationProducts
  • Caregiver Mobile AppProducts › Electronic Visit Verification

Compliance & Security · Interoperability

Interoperability at Elixir:FHIR APIs and HL7 Exchange

FHIR and HL7 v2 are routinely named together and do almost entirely different jobs. One is how applications and payers read your data through an API. The other is how your lab results and admission notifications have arrived every day for twenty years. A behavioral health organization needs both, and should expect a vendor to be clear about which is which.

  • HL7 v2

    Message-based exchange with the systems around you. Lab orders and results, admission, discharge and transfer notifications, immunization and registry reporting. Unglamorous, and the layer most clinical days actually depend on.

  • FHIR

    API-based access to discrete data. Elixir publishes FHIR-formatted resource endpoints and a C-CDA all-data request under the application access criterion it is certified to, with the documentation open to read before anyone signs anything.

  • The obligation

    As a certified health IT developer, Elixir is bound by the information blocking Condition of Certification. That is a legal duty on us, not a feature we enable.

  • Both layers, not one

    FHIR-formatted resource endpoints and C-CDA document exchange, alongside HL7 v2 interfaces for the systems that have always worked that way.

  • Certified, not asserted

    Elixir’s certified criteria are listed publicly, criterion by criterion, so you can read what was tested rather than take a claim on trust.

  • Part 2 handled, not avoided

    Substance use disorder records carry consent obligations that general interoperability guidance does not address. They are addressed here.

  • A duty we carry

    Information blocking binds certified developers directly, with civil money penalties and public posting for those found in breach.

The distinction

FHIR and HL7 v2 Do Different Jobs. Both Still Matter.

Vendor material tends to treat FHIR as the modern replacement for HL7 v2. In practice the two coexist, they solve different problems, and an organization that buys on FHIR alone will discover the gap during implementation.

HL7 v2: the exchange that already runs your day

Message-based, point-to-point, and in production almost everywhere. Lab orders going out and results coming back. Admission, discharge and transfer notifications arriving from a hospital. Registry and immunization reporting going to a state.

For a behavioral health or addiction treatment organization this is where the operational value sits. A toxicology result that lands in the chart as discrete data rather than a faxed PDF changes a clinical workflow. A discharge notification that arrives as an event rather than a phone call starts a transitional care clock. Neither requires FHIR.

FHIR: the API layer, and what to check

Resource-based and request-driven. An application asks for specific data and receives it as structured resources, rather than an interface being built for each counterparty.

Where Elixir sits. Elixir is certified for application access — patient selection, which is the criterion that governs published API documentation, and it publishes FHIR-formatted resource endpoints and a C-CDA all-data request on top of it. It is not certified to the standardized API criterion, which is a separate criterion with its own US Core and SMART App Launch requirements. We say so plainly because the two are routinely conflated, and because the full criteria list is published on our ONC Certification page where anyone can check. If a federal program you participate in requires the standardized API criterion, raise it with us early rather than late.

The endpoints, authentication, error handling and terms are documented in full in the API Developer Portal — open to read, with no registration.

  • The data standard is USCDI v3

    USCDI version 3 is the current baseline for certification criteria that reference it. Version 1 expired for Certification Program purposes at the start of 2026. Later versions exist and are available for voluntary adoption, but are not the required baseline.

  • Documents still travel as documents

    Consolidated CDA remains how a summary of care actually moves at a transition, and Elixir is certified for transitions of care, C-CDA creation performance against the HL7 C-CDA Release 2.1 guide, and electronic health information export. API access and document exchange are complementary rather than alternatives.

  • Clinical content, not just transport

    Moving a record is the easy half. Whether the receiving clinician can act on it depends on coded problems, medications, allergies and results — which is a data quality question, not a protocol one.

The obligation

Information Blocking Binds Us Directly, Not Only Our Customers

Most coverage of information blocking addresses providers. The rules reach certified health IT developers separately, and the consequences differ materially.

  • For developers

    Civil money penalties of up to $1 million per violation

    Developers of certified health IT, health information exchanges and health information networks are subject to civil money penalties enforced through the Office of Inspector General. That is a direct financial exposure on the vendor, assessed per violation.

  • For providers

    Disincentives rather than penalties

    Health care providers found to have committed information blocking face payment consequences instead — a reduced market basket update under the Medicare Promoting Interoperability Program, a zero score in the Promoting Interoperability performance category for clinicians, or ineligibility to participate in the Medicare Shared Savings Program for at least a year.

  • Either way

    Public posting

    Actors found to have committed information blocking — providers, certified developers and networks alike — are posted publicly. For most organizations that is the consequence that matters more than the money.

  • The conditions

    Information blocking is one of several Conditions of Certification

    Alongside it sit assurances, communications, application programming interfaces, real world testing, attestations and the Insights condition. A certified developer must maintain all of them continuously, not demonstrate them once. Real world testing in particular runs on an annual cycle of published plans and published results.

One provision worth knowing as a customer: the communications condition means we may not contractually restrict you from discussing our product’s usability, security, user experience, interoperability or costs. If a vendor asks you to sign something that does, that is itself a problem.

Behavioral health

The Exceptions That Matter When Part 2 Records Are Involved

General interoperability guidance is written for a world where consent is not the central question. In addiction treatment it is.

The practical risk runs both ways

  • Over-disclosing substance use disorder records without the consent the rules require is a confidentiality breach, now civilly enforceable.
  • Over-withholding — treating Part 2 as a reason to refuse exchange generally — risks being information blocking.
  • The answer to both is the same: consent captured as data, so what may be released is a system determination rather than a judgment call made under time pressure.

The regulations anticipate this. Information blocking carries a defined set of exceptions, grouped into those covering a decision not to fulfill a request and those covering the manner in which a request is fulfilled. Among the first group are exceptions addressing privacy, security, preventing harm, infeasibility and health IT performance.

The privacy exception is the relevant one here. Where another law requires a consent or authorization that has not been obtained, declining to release is not automatically information blocking. That is the mechanism by which substance use disorder confidentiality and the information blocking rules coexist — but it is conditional, and relying on it requires that the condition genuinely applies and can be evidenced.

Which makes this an engineering question rather than a policy one. If consent status, scope, expiry and revocation live in the record as structured data, then whether a given disclosure is permitted can be determined consistently and shown afterwards. If consent lives in a scanned form, every request becomes an individual judgment, and neither answer — release or refuse — is defensible later.

Part 2 became subject to civil enforcement in February 2026. The consent model, redisclosure rules and breach notification position are covered on the HIPAA Compliance Center, and the clinical workflow on our substance use disorder EHR page.

The moving parts

What Is in Force, and What Is Still Proposed

Interoperability regulation moves faster than almost anything else in health IT, and vendor material frequently reports proposals as though they were requirements. The position as at November 2026 is below.

In force

Current obligations

  • USCDI version 3 as the certification baseline; version 1 expired at the start of 2026
  • Standardized API support for the current US Core implementation guide and SMART App Launch specification
  • Service base URLs published in a standardized format, at no charge
  • Information blocking, with ten defined exceptions across three groups
  • Updated payer data exchange standards, effective from October 2026

Running now

The Insights condition

  • The first data collection period for the Insights Condition of Certification runs across calendar year 2026
  • First submission falls due in 2027
  • It is a reporting obligation on certified developers rather than on customers
  • Several enforcement discretion notices are currently active across certification criteria dates, attestations, real world testing and other requirements — so published deadlines should be checked against the current notices rather than assumed

Proposed only

Drug prior authorization

  • A proposed rule published in April 2026 would extend prior authorization interoperability requirements to drugs, with comments closed in June 2026
  • It has not been finalized. Anything described as a drug prior authorization requirement is not yet law
  • The standards proposed alongside it were finalized separately through a payment rule and took effect in October 2026 — which is a distinction worth holding, because the two are routinely conflated

Dates, standard versions and enforcement positions in this area change several times a year. We would encourage you to confirm anything load-bearing against the current rules rather than against any vendor’s summary, ours included.

Integration planning

Which interfaces do you actually need?

Most integration scope is settled by three questions: which labs you use, which hospitals discharge to you, and which payers you contract with. We would rather work through those than send you a standards list.