eleven88

Healthcare interoperability, engineered.

Healthcare depends on systems built across decades of technology. We design the infrastructure that connects them — and build the open-source message-processing platform it runs on.

See the products Talk with an architect

HL7 v2FHIR R4US CoreDa VinciC-CDAX12REST APIsCloud platformsData platforms

Healthcare connectivity has become infrastructure.

Healthcare organizations operate hundreds of applications, interfaces, standards, and data flows. Most were never designed to work together.

So connectivity gets built one interface at a time: point-to-point integrations, duplicated transformation logic, inconsistent data models, and limited visibility into what is actually moving.

The challenge is not simply moving data from one place to another. It is transforming data so that its meaning is preserved, its quality is improved, and its value can be used across the organization.

We design the architecture that connects them.

eleven88 builds interoperability and data infrastructure across legacy healthcare systems, standards, APIs, and modern cloud platforms — as a platform the organization can build on, not as another interface.

The eleven88 data path: source systems, acquisition, validation, transformation, canonical data, and exchange — six stages connected in sequence. 01 02 03 04 05 06 SOURCE ACQUISITION VALIDATION TRANSFORMATION CANONICAL EXCHANGE EHRs, labs, claims, files MLLP, SFTP, APIs, events Conformance and quality Meaning preserved One consistent model FHIR APIs, analytics, apps
  1. 01SOURCEEHRs, labs, pharmacy, claims, files, and legacy feeds
  2. 02ACQUISITIONReliable intake across MLLP, SFTP, APIs, and events
  3. 03VALIDATIONConformance and data-quality checks before anything lands
  4. 04TRANSFORMATIONMapping and normalization that preserves meaning
  5. 05CANONICALOne consistent model the organization can build on
  6. 06EXCHANGEFHIR APIs, analytics, and downstream applications

Products

Four components, one message-processing pipeline. Produce realistic test messages, receive production feeds, project them into a canonical model, and watch every step. The pipeline is open source; ClaimForge is the commercial product.

  1. Produce
    eleven88 / claimforge

    ClaimForge Commercial

    Synthetic healthcare messages for engineering, QA, demo environments, and training pipelines — realistic enough to break things in the right places, without touching PHI.

    • HL7 v2, X12 claims, and FHIR bundles from one schema-aware generator
    • Seeded, reproducible fixtures for CI; volume generation for load tests
    • Realistic mess by design: Z-segments, truncation, duplicate MRNs, out-of-order timestamps
  2. Receive
    eleven88 / ingestion

    Ingestion Open source

    Reliable intake from trading partners and feeds, with a durable identity and provenance record for every message that crosses the boundary.

    • MLLP, SFTP batch, REST and FHIR subscriptions, vendor APIs
    • HL7 ACK/NACK, HTTP, and file-level acknowledgement semantics
    • At-least-once delivery with idempotent processing; quarantine, dead-letter, and replay — nothing is dropped silently
  3. Interpret
    eleven88 / projector

    Projector Open source

    Projects raw messages into the eleven88 canonical model — patients, encounters, orders, observations, claims — with terminology mapped and lineage preserved.

    • Versioned, deterministic mappings; reprocess history when a rule changes
    • Field-level lineage from every canonical value back to its source segment
    • ICD-10, CPT, LOINC, SNOMED CT, RxNorm, and NDC crosswalks; unmapped values quarantined, never guessed
  4. Observe
    eleven88 / dashboard

    Dashboard Open source

    Operational monitoring that lets people trust the pipeline: queue depth, latency, error spikes, and the journey of any single message.

    • Drill from a partner-level view to one message in a few clicks
    • Data-quality signals alongside throughput, for informatics as well as ops
    • Alerting on stalled feeds and error rates, tuned to avoid alert fatigue
  • Built as an estate, not a bridge. Versioned message contracts, long-term support releases, and deprecation windows measured in years — hospital IT does not upgrade quarterly.
  • Auditable by construction. Every transformation is deterministic and traceable to its source. A mis-mapped code is a patient-safety and revenue-integrity issue, so it has to be findable.
  • Open where it builds trust. Ingestion, Projector mappings, and the Dashboard are open source under a permissive license. Contributed mappings go through review before they are marked production-grade.

Ask about early access

Capabilities

The engineering practice around the products. Four disciplines, one integrated team.

  • eleven88 / interoperability

    Interoperability

    Design and implementation of healthcare data exchange on established standards, so systems can share information without every application having to understand every other application.

    • HL7 v2
    • FHIR R4
    • US Core
    • Da Vinci
    • C-CDA
    • X12
  • eleven88 / data

    Data platforms

    Architectures for acquiring, transforming, normalizing, storing, and distributing healthcare data: ingestion pipelines, canonical models, terminology mapping, and schema management.

    • Canonical models
    • Transformation
    • SNOMED CT
    • LOINC
    • RxNorm
  • eleven88 / architecture

    Architecture

    Platform, integration, cloud, and API architecture for interoperability programs — current state, target state, and a migration path grounded in the estate that actually exists.

    • FHIR architecture
    • API platforms
    • Event-driven
    • Cloud-native
  • eleven88 / engineering

    Engineering

    Implementation of reliable integration infrastructure: APIs, FHIR services, message processing, transformation engines, and the automated testing that keeps them correct.

    • FHIR services
    • Message processing
    • Automated testing
    • Observability

Where integration fails

Four conditions account for most integration failure in healthcare data estates. Each is stated the way it would appear in an assessment, with the remediation that follows from it.

  • F-01

    Local codes carry meaning the receiving system cannot read.

    Result values arrive as site-specific mnemonics. Units are inconsistent or absent. The same concept is represented three ways across three source systems, and the downstream warehouse treats them as three different things.

    RemediationSource analysis and schema discovery, semantic mapping to standard terminologies, unit and value normalization, and validation with the provenance to show what was changed and why.

  • F-02

    Transport succeeds. Semantics do not.

    An interface is declared healthy because messages are being acknowledged. Conformance to the profile is never tested, cardinality violations pass silently, and the failure surfaces months later in a report nobody trusts.

    RemediationInteroperability architecture that treats semantic conformance, validation, privacy, and observability as first-class concerns rather than a layer above transport.

  • F-03

    The design has no owner between approval and production.

    An architecture is agreed, then handed across a gap — to a vendor, to an internal team already at capacity, to whoever is free. The decisions that made the design correct are not written down anywhere the implementers will read.

    RemediationFull-lifecycle implementation, from discovery through design, development, conformance testing, deployment, and production readiness. The person who drew it builds it.

  • F-04

    Go-live is treated as the finish line.

    Monitoring covers uptime but not data quality. Exceptions accumulate in a queue with no owner. Nobody can answer how many records failed last week, or which ones, or why.

    RemediationOperational visibility built in: monitoring and alerting, exception workflow, data-quality reporting, and post-go-live stabilization and optimization.

Standards in scope

Standards are not a checklist. Named precisely, they are the difference between a system that exchanges information and one that merely transmits it.

  • HL7 FHIR

    API strategy, resource modeling and profiling, conformance validation, and payer / provider exchange.

    • R4
    • US Core
    • Da Vinci
    • Bulk Data
    • SMART

  • HL7 v2

    Interface analysis, parsing, transformation, validation, and modernization of feeds that have been running for longer than anyone remembers.

    • ADT
    • ORM
    • ORU
    • SIU
    • MDM
    • MLLP

  • C-CDA / CCD

    Clinical document ingestion, normalization, extraction, and exchange — including the documents that are technically valid and semantically useless.

    • CCD
    • Referral Note
    • Discharge Summary

  • X12 & payer data

    Transaction integration, workflow alignment, payer-provider exchange, and legacy-to-modern transformation with data integrity preserved.

    • 270/271
    • 276/277
    • 834
    • 835
    • 837

  • Terminology

    Mapping and normalization across the code systems that decide whether two records are talking about the same thing.

    • SNOMED CT
    • LOINC
    • RxNorm
    • ICD-10-CM
    • CVX
    • UCUM

How the work runs

A sequence, in order. Each stage produces something the next one needs. Build interoperability as a platform, not another interface.

  1. Stage 1

    Discover

    Stakeholders, systems, data, constraints, risks, and the outcome that actually matters. Most integration failures are visible here and ignored.

  2. Stage 2

    Design

    Target architecture, information models, standards selection, controls, and a roadmap grounded in the estate and the delivery capacity that exists.

  3. Stage 3

    Deliver

    Build, validate, document, deploy. Conformance tested rather than assumed, and documented so the next person can maintain it.

  4. Stage 4

    Operate

    Monitor performance and data quality, resolve exceptions, and improve reliability over time. Going live is not the finish line.

We build the infrastructure between healthcare systems.

Healthcare technology has evolved over decades. Mainframes coexist with cloud platforms. HL7 interfaces coexist with FHIR APIs. Batch files coexist with event streams. None of this is going away overnight.

The challenge is creating an architecture where these systems can operate together reliably. That is where eleven88 works.

eleven88 is a focused engineering practice, not an agency. The person who assesses your estate is the person who designs the solution and the person who builds it.

John Waldron · Founder / Principal Architect

John has spent [N] years in healthcare informatics and integration engineering, including [PRIOR ROLES / ORGANIZATIONS]. [CERTIFICATIONS AND CREDENTIALS]

Let’s design what connects next.

If you are planning a FHIR program, modernizing HL7 interfaces, or building a healthcare data platform, there is usually a short conversation that saves a long project.

Talk with an architect

Or write directly to [CONFIRMED EMAIL ADDRESS]