Firely Server provides FHIR infrastructure—but a running endpoint is not conformance

FHIR-capable infrastructure is the start of an implementation claim

Firely's official product record places Firely Server inside a specialist FHIR portfolio that includes server infrastructure, APIs, SDKs, validation and conformance tooling, and implementation services. A server can provide a practical foundation for storing and exchanging FHIR resources, applying supported features, and exposing endpoints to applications. That can reduce the amount of protocol and resource plumbing an implementation team has to build itself.

The presence of a running endpoint answers only a narrow question: a service responded under the conditions tested. Interoperability depends on a declared FHIR release and implementation guide, supported profiles and extensions, required and optional elements, terminology bindings, identifiers, references, search parameters, operations, pagination, errors, authorization, provenance, consent and policy, performance, and the workflow meaning assigned to exchanged data. Those decisions belong to the implementation.

Conformance needs a versioned claim and reproducible evidence

Teams should publish or retain the applicable capability statement, implementation-guide versions, profile packages, terminology versions, supported interactions, security model, and known limitations. Validation should show more than syntactic resource acceptance. A resource may satisfy base FHIR while failing a required profile, use a valid code from the wrong value set version, omit data the receiving workflow depends on, or preserve a reference that cannot be resolved in the target environment.

The handoff should connect each test result to the endpoint version, software and configuration, test data, actor, request, response, headers, authorization context, validator and ruleset, terminology service, expected assertion, observed outcome, defect, waiver, and retest. A passing badge or dashboard count without that lineage is difficult to use during a release review or later incident. Production monitoring should distinguish uptime from semantic and workflow correctness.

Test a real exchange path, including failure

A representative evaluation should create, search, update, and retrieve resources used in one actual workflow, with profiles and terminology expected by both parties. It should include unsupported data, an invalid code, missing required element, unresolved reference, duplicate identifier, version conflict, authorization failure, consent restriction, partial batch or transaction, pagination, and an operation outside the declared capability. The client should handle both FHIR OperationOutcome details and transport-level errors without treating any HTTP response as clinical success.

Firely's public record supports its described FHIR product scope, but no configured server, profile, terminology, security control, validator, implementation guide, performance characteristic, exchange, or customer outcome was independently tested here. Developers, clinical informaticists, interface teams, security and privacy owners, data-governance leaders, trading partners, and legal and compliance teams must define the production claim. FHIR infrastructure can support conformance work; it does not certify interoperability, data completeness, clinical fitness, or lawful disclosure.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.