Direct Answer: What a 2026 FHIR R5 Checklist Must Prove
A useful FHIR R5 implementation checklist is not a list of supported resources. It is evidence that a care-coordination or patient-pulse workflow can exchange the right data, through the right FHIR version, with the right security and operational controls, in a partner's environment. For a clinic or care network, the minimum defensible baseline is 100% of the organization's declared endpoints and resources documented by FHIR version, 100% of required scopes and user stories mapped to SMART-on-FHIR authorization, 100% of mandatory data elements tested with valid and invalid payloads, and 100% of audit events reviewed before production. A team should also complete at least 30 consecutive days of monitored pilot data or an equivalent risk-based period, with zero unresolved severity-one defects and an agreed disposition for every lower-severity defect.
Also worth reading: How Should Health IT Teams Approach FHIR R4 Implementation Testing in 2026? · How do you build a patient engagement software implementation roadmap for clinics and care networks? · How Do You Choose the Right Care Coordination Software for Your Clinic Network?
FHIR R5, published by HL7 as Release 5 in March 2023, is a normative specification, but that does not make every R5 feature interoperable in every deployment. R5 adds resources and capabilities relevant to care coordination, including Definition, SubscriptionStatus, Communication, Task, and more explicit support for event-driven workflows. It also contains trial-use material, and many US EHRs still expose R4 or R4B endpoints through production SMART APIs. The practical answer is therefore version-aware: use R5 where the partner and workflow support it, use R4 where the production contract requires it, and never assume that an R4 request will work on an R5 endpoint or that an R5 resource will be accepted unchanged by an R4 server.
For a care network, the checklist should cover data contracts, authorization, terminology, workflow state, patient matching, subscriptions, performance, security, observability, release controls, and vendor exit. A reasonable implementation takes 8-16 weeks for one well-scoped integration and 4-9 months for a multi-site network with several EHRs, because discovery, sandbox access, terminology mapping, and partner testing usually consume more time than the first REST call. The budget should include engineering, interface analysis, security review, testing, monitoring, and contingency; a useful planning range is roughly $40,000-$150,000 per initial integration and $15,000-$60,000 for each materially different site or EHR profile, with recurring operations often adding 15-25% of initial build cost per year.
Scope and Version: What Must Be in the Contract
The first section of the checklist should define the workflow before naming resources. Write a one-page use-case statement that identifies the initiating actor, the target actor, the clinical or operational event, the data needed, the response expected, and the failure behavior. For patient-pulse collection, that may mean creating or referencing a Questionnaire, submitting a QuestionnaireResponse, linking it to a Patient and Encounter, and routing an Observation or Communication to a care team. For referral coordination, the same workflow may involve ServiceRequest, Task, Practitioner, Organization, Location, Communication, and Provenance. The checklist should state which of these are mandatory for launch and which are optional extensions, rather than treating every resource mentioned in a design document as an implementation requirement.
Next, create a version matrix for every connection. Record the FHIR base URL, release, capability statement, supported interaction, search parameters, profile, terminology service, and known server limitations. A single care network can legitimately have an R4 endpoint for one EHR, an R4B endpoint for another, and an R5 endpoint for a research or newer coordination platform. That is not a failure of FHIR; it is a normal integration condition. The matrix should also identify whether the server is an official EHR endpoint, a vendor-managed integration service, a sandbox, or a custom gateway, because those environments often have different rate limits and support expectations.
The final scope artifact is a traceability table linking each workflow step to a resource, profile, operation, authorization scope, test case, owner, and acceptance criterion. A practical threshold is to require a named owner and a passing test for 100% of launch-critical paths, while allowing documented future work for non-launch features. If a requirement cannot be tested, it is not yet an implementation requirement; it is a design aspiration. This distinction keeps the project focused on measurable exchange rather than a long list of FHIR nouns.
Workflow Design: How the Data Actually Moves
A care-coordination implementation should model states, not just resources. A questionnaire can be sent, partially answered, completed, reviewed, escalated, or ignored; a referral can be drafted, accepted, scheduled, completed, cancelled, or rejected. FHIR resources carry statuses, but the network must define the business meaning of each status and the permitted transitions. For example, a QuestionnaireResponse marked completed should not automatically become a clinical alert unless the organization has defined the scoring rule, review queue, response time, and responsible team. A Task can represent the work item, while Communication can record the notification, but the implementation must decide which system is authoritative for each state.
Identifiers are a common source of silent errors. Every message should preserve the source identifier, assign a local identifier where needed, and record provenance so that a response can be matched to the original request. Patient identity deserves a separate control: use at least two demographic match factors for routine matching, and require manual review or a documented exception path when name, date of birth, address, or identifier confidence is weak. A high-confidence automated match threshold should be defined by the organization, but it should not be presented as a universal FHIR number because matching quality depends on the population and source data.
The workflow section should also specify timing and failure behavior. Define expected latency for synchronous reads, asynchronous submissions, subscriptions, and human review. For a patient-pulse alert, a common target is submission acknowledgement within 5 seconds and triage visibility within 60 seconds, but the clinical owner must approve those targets. Define retry counts, idempotency keys, duplicate handling, and dead-letter handling before testing begins. Without these rules, a transient outage can create duplicate alerts, missing responses, or an inbox that appears healthy while messages are stuck in a queue.
Security, Consent, and Authorization Controls
Security review should begin with the data classification and the minimum necessary data set, not with a generic statement that the platform is encrypted. Identify whether the integration uses SMART-on-FHIR user authorization, system-to-system authorization, or both. For SMART-on-FHIR, document the launch context, redirect URI, PKCE flow, requested scopes, token lifetime, refresh policy, and revocation behavior. A production checklist should verify that scopes are limited to the resources and operations actually used; requesting broad read access because it is convenient increases risk and often causes partner rejection.
Transport and data protection controls should be testable. Require TLS 1.2 or newer for every endpoint, validate certificate chains and hostname handling, and confirm that secrets are stored in a managed secret system rather than source code or a shared spreadsheet. At rest, use encryption appropriate to the hosting environment and define key rotation, backup retention, and deletion behavior. Audit logs should capture the actor, patient or encounter reference, action, timestamp, source, outcome, and correlation identifier without copying unnecessary clinical content into logs. A useful threshold is 100% coverage of authentication, authorization, data access, export, and administrative changes by auditable events.
Consent is not a single FHIR flag. The implementation should identify the legal basis, the patient's choice, the purpose of use, the recipient, the time period, and the mechanism for changing or withdrawing consent. Where a Consent resource is used, map its status and provision semantics carefully; where the EHR represents consent in a proprietary field, document the translation and the human review path. The checklist should include at least one test for a patient who permits sharing, one who restricts a category, one whose consent has expired, and one whose identity cannot be confidently matched. Security sign-off should require no unresolved high-risk findings and a documented owner for every accepted exception.
Data, Terminology, and Provenance Quality
The data section should begin with a field-level contract. For every element, record the source system, FHIR path, cardinality, requiredness, value set, update frequency, owner, and transformation rule. A patient-pulse response may look simple at the interface level, but the Questionnaire item IDs, Observation codes, units, effective time, performer, and QuestionnaireResponse status all need explicit mappings. Avoid sending a display string when a coded value is expected, and avoid treating a missing value as a normal zero. The acceptance test should include missing, malformed, out-of-range, duplicate, and late-arriving values.
Terminology work is often underestimated. Decide which code systems are authoritative for observations, questions, conditions, medications, locations, and organizational roles, and record the version or release date for each. Use a terminology server or validated value-set expansion process where possible, and test that codes are valid in the target system rather than merely syntactically plausible. R5's canonical URLs and versioning rules can improve precision, but they do not remove the need for local mapping when an EHR uses a proprietary extension or an older code version. A practical target is 100% of launch codes resolved or explicitly mapped, with no unreviewed fallback codes in production.
Provenance and history should be designed as first-class data. Record who created or changed a resource, when it happened, which source supplied it, and whether the value was transformed. Use Provenance where the exchange needs an auditable origin, and preserve the original payload or a stable reference when the workflow may need reconstruction. For patient-pulse data, distinguish the time the patient answered from the time the response was received and the time a clinician reviewed it. These timestamps are not interchangeable, and collapsing them can distort care-team dashboards. The data owner should approve a reconciliation report comparing source counts, accepted resources, rejected resources, and unresolved exceptions at least daily during the pilot.
API, Performance, and Reliability Engineering
Start API testing with the CapabilityStatement and then test every interaction the workflow actually uses. Confirm read, search, create, update, patch, history, and operation behavior only where required; unnecessary interactions add testing burden and may be unsupported. Search tests should cover required parameters, date ranges, pagination, sorting, and the server's actual behavior when a parameter is absent. For R5 subscriptions, verify the channel type, event criteria, payload shape, retry behavior, and SubscriptionStatus handling against the server's documented implementation. Do not assume that a server advertising subscriptions supports every R5 event or delivery format.
Performance criteria should be tied to clinical workflow. A care coordinator may tolerate a 2-minute background synchronization for a non-urgent referral, while a patient-pulse escalation may need acknowledgement in seconds and human visibility within a minute. Record baseline latency, p95 latency, error rate, throughput, and queue depth during a representative test. A useful starting threshold is p95 response time below 2 seconds for common reads, below 5 seconds for submissions, and an error rate below 1% excluding documented partner outages, but the final targets should reflect the use case and service agreement. Load tests should include at least 2 times the expected peak volume for 30 minutes and a 15-minute degradation scenario.
Reliability controls should make failure visible and recoverable. Use idempotency keys for submissions that may be retried, retain correlation identifiers across client, gateway, and EHR logs, and define a replay procedure for failed messages. Alerts should distinguish authentication failures, validation failures, partner outages, and application errors because each requires a different response. The team should run at least one planned outage test, one credential-expiry test, one duplicate-message test, and one clock-skew or timestamp test before go-live. A clean interface with no monitoring is not reliable; it is merely unobserved.
Validation, Partner Conformance, and Go-Live Gates
Validation should combine automated conformance checks, scenario tests, and partner review. Validate every outgoing resource against the selected FHIR release, profile, and terminology constraints, and test inbound resources for graceful handling of unknown extensions and unexpected cardinality. A useful gate is 100% pass rate for launch-critical scenarios, 95% or higher for non-critical scenarios, and zero open defects rated severity one or two. Severity definitions should be written in advance: severity one blocks patient safety or data integrity, severity two blocks a core workflow, and severity three is a limited defect with a safe workaround.
Partner testing is not optional merely because a sandbox passed. Schedule a formal endpoint review, exchange capability statements, confirm supported profiles and scopes, and run representative records through the production-like environment. Ask the partner to demonstrate token refresh, rate-limit behavior, subscription delivery, and error responses rather than relying on a configuration screenshot. Record the partner's support contact, escalation route, maintenance window, and expected response time. If the partner cannot provide a stable test environment, treat that as a delivery risk and limit the initial launch to a low-volume pilot.
The go-live gate should be signed by clinical operations, engineering, security, privacy, and the partner owner. Require a rollback plan, a data-reconciliation report, a support rota, and a post-launch review date. A practical pilot begins with 10-25 patients or 5-10 care-team users for 2-4 weeks, followed by expansion only if error rates, duplicate rates, response times, and manual workarounds remain within agreed limits. Do not declare success because the first message arrived; declare success after the system has handled normal variation, failure, correction, and human review. The final release record should link the tested build, endpoint configuration, profiles, value sets, and approval evidence so that the deployment can be reproduced.
Costs, Timeline, and Build Versus Integration Choices
Cost depends more on partner variability and workflow complexity than on the FHIR version label. A single-site implementation with one EHR, one questionnaire, and a narrow care-coordination workflow may require 600-1,200 engineering and analysis hours, while a network with multiple EHRs, local terminology differences, and custom consent rules can require 2,000-5,000 hours or more. The earlier range often translates to roughly $40,000-$150,000 in blended delivery cost, depending on labor rates and vendor fees; the larger range can exceed $300,000 when security review, data migration, and partner-specific testing are included. Recurring costs commonly include hosting, monitoring, terminology services, support, and change management, often 15-25% of initial build cost annually.
The timeline should be planned in stages rather than as one implementation date. Spend 2-4 weeks on discovery and data mapping, 3-6 weeks on authorization and API build, 3-6 weeks on terminology and workflow testing, and 2-4 weeks on partner validation and pilot. Multi-site rollouts should add 2-6 weeks per materially different endpoint or governance model, with parallel work only where the profiles and contracts are stable. A team can reduce elapsed time by reusing a canonical internal model and maintaining a library of partner profiles, but it should not hide local differences behind a generic adapter. The honest schedule includes time for partner delays, which are common even when the software team is ready.
A build-versus-buy decision should compare control, speed, and long-term maintenance. Building an adapter gives the organization direct control over transformations and observability, but it creates a permanent engineering responsibility. Buying a managed integration service can shorten the first connection and provide certification support, but it may limit custom workflow behavior and create dependency on the vendor's release schedule. A hybrid model is often sensible: use a managed FHIR gateway for transport, authorization, and baseline validation, while keeping care-coordination state, patient-pulse logic, and clinical routing in the application that owns the workflow. The decision should be revisited after the second or third endpoint, when integration debt becomes measurable rather than theoretical.
Common Mistakes, Red Flags, and When to Act
The most common mistake is treating FHIR R5 as a switch that makes all systems interoperable. A server can advertise R5 while supporting only a subset of resources, using local profiles, omitting subscriptions, or returning R4-shaped data behind an R5 endpoint. Another mistake is designing around happy-path examples and ignoring missing values, duplicate patients, expired tokens, late responses, and partial updates. A third is assuming that a QuestionnaireResponse is automatically understandable to a care team; without scoring, routing, ownership, and review rules, it is only a structured payload. The checklist should therefore test behavior under imperfect conditions, not just schema validity.
Red flags should trigger a pause before go-live. Examples include an endpoint with no documented CapabilityStatement, a partner that cannot explain rate limits, a production token shared across environments, an unowned mapping table, or a pilot with no reconciliation report. Another warning sign is a requirement to send more data than the workflow needs because the team has not defined minimum necessary access. Security findings should not be accepted merely to meet a launch date unless the residual risk is documented, time-bounded, and approved by the appropriate owner. If a defect can create duplicate clinical alerts or misattribute a response to the wrong patient, it is not a cosmetic issue.
Act when the organization has a repeatable workflow, a named clinical owner, a partner endpoint or a credible path to one, and a measurable reason to exchange data. For a clinic evaluating a patient-pulse SaaS, the right time to start is before selecting a vendor or promising a rollout date, because FHIR capability varies sharply across EHRs and contracts. For a care network, begin with one high-value workflow and one representative site, then expand after the pilot demonstrates stable data quality and support operations. Waiting for every possible resource or every partner to support R5 can delay useful coordination work, but launching without version and failure controls can create a more expensive cleanup. The best time to act is when the team can define the first workflow precisely and can afford to test it properly.