Blockchain Development Services Healthcare CIOs Should Consider Before Their Next RFP

Healthcare CIOs face a 24–36 month window where TEFCA, CMS API rules, DSCSA, and NIST’s security updates converge. This post maps those regulatory milestones to concrete blockchain development services—what to buy, build, and ask vendors—so you can issue a sharper RFP and de‑risk delivery.

---

Who this is for

Decision‑makers at health systems, payers, life sciences, and digital health startups evaluating blockchain to solve specific interoperability, compliance, and security problems.

---

TL;DR description

US interoperability and supply‑chain rules changed in 2024–2025. TEFCA added FHIR pathways, CMS finalized FHIR APIs (most due Jan 1, 2027), DSCSA enforcement and exemptions phase through 2025–2026, and NIST issued post‑quantum FIPS and CSF 2.0. Here’s exactly which blockchain development services to consider—identity, audit, supply chain, consent, and more—and how to spec them in your next RFP. (sequoiaproject.org)

---

Why “now”: four deadlines that should shape your scope

• TEFCA’s Common Agreement v2.0/v2.1: Added FHIR API exchange “facilitated FHIR” with QTF v2.0 and new SOPs; QHIN‑to‑QHIN FHIR pilots began planning in 2025, progressing the staged roadmap. Bake TEFCA alignment into your data‑exchange architecture. (sequoiaproject.org)
• CMS Interoperability & Prior Authorization Final Rule (CMS‑0057‑F): Payers must stand up Patient/Provider/Payer‑to‑Payer/PA FHIR APIs; most API compliance dates are Jan 1, 2027; metric reporting begins 2026; HHS allowed HIPAA enforcement discretion so FHIR‑only PA APIs can fly (no mandatory X12 278 in that context). (cms.gov)
• DSCSA: FDA’s stabilization period (Nov 2023→Nov 2024) was followed by targeted exemptions by partner type (e.g., manufacturers/repackagers to May 27, 2025; wholesalers to Aug 27, 2025; dispensers ≥26 FTE to Nov 27, 2025; small dispensers to Nov 27, 2026). Your serialization/EPCIS stack and auditability must handle mixed readiness. (fda.gov)
• Security: NIST approved three post‑quantum FIPS (203/204/205) in Aug 2024, and CSF 2.0 added a new Govern function—your RFP should require crypto‑agility and CSF 2.0 alignment. (nist.gov)

---

1) TEFCA‑ready data exchange services (FHIR + network trust)

What to buy/build:

• TEFCA policy/technical gap assessment and “QHIN interface readiness” plan (mapping your exchange purposes to TEFCA SOPs; routing via your QHIN or a delegate). (sequoiaproject.org)
• A “facilitated FHIR” gateway: FHIR R4.0.1 facade with patient‑ and population‑level access, query brokering through your QHIN, and a TEFCA‑compliant trust/onboarding workflow. (healthit.gov)
• TEFCA audit hooks: persist signed transaction summaries off‑chain and a tamper‑evident hash on‑chain; emit FHIR AuditEvent and Provenance per access. (hl7.org)

Practicals for the RFP:

• Require support for Common Agreement v2.x semantics (delegation, governance, IAS) and QTF v2.0. Ask bidders to show message flows for “facilitated FHIR” and how identity assertions, purpose‑of‑use, and break‑glass are captured on chain. (sequoiaproject.org)
• Ask for a migration path to Stage 3/4 TEFCA FHIR exchange (QHIN‑to‑QHIN and end‑to‑end), with a test plan aligned to the pilot roadmap. (hcinnovationgroup.com)

Example:

• A multi‑state provider deploys a permissioned ledger to notarize FHIR Bundle digests exchanged via its QHIN. The on‑chain record stores only hashes and metadata (purpose, consent reference), while the full payload remains in your FHIR servers—satisfying TEFCA auditability without moving PHI onto the ledger. (hl7.org)

---

2) Payer API modernization: combine FHIR compliance with blockchain proofs

Required APIs and standards to reflect in scope:

• Patient Access, Provider Access, Payer‑to‑Payer, and Prior Authorization APIs using HL7 FHIR R4.0.1, SMART App Launch, OpenID Connect, Bulk Data (Flat FHIR); with recommended Da Vinci/CARIN guides. Most API compliance dates are Jan 1, 2027 (operational reporting begins 2026). (cms.gov)

Where blockchain helps (and where it doesn’t):

• Do use it to notarize prior‑auth lifecycle events, consent artifacts, and payer‑provider data sharing attestations; make these verifiable and immutable for audits.
• Don’t put clinical data or full adjudication payloads on chain; keep PHI in your FHIR stores; chain holds hashes, timestamps, actor DIDs, and pointers.

RFP questions:

• Show how your design supports a FHIR‑only PA API (given HIPAA enforcement discretion) and how you’ll interoperate with trading partners that still prefer X12. (cms.gov)
• Demonstrate conformance to the specific guides CMS references (PDex, CRD, DTR, PAS) and how your ledger audit ties to each API call. (cms.gov)

---

3) Drug supply chain: DSCSA‑grade traceability with EPCIS + verifiable logs

Your stack should handle mixed‑state partners during the 2025–2026 exemption windows and progress to EPCIS conformance. (fda.gov)

Core services to include:

• EPCIS 1.2 minimum and a path to R1.3: implement capture/query services and conformance testing across manufacturers, wholesalers, dispensers. GS1 indicates minimum adoption of R1.2 with a “sunrise” for R1.3 beginning with dispensers (Q3 2026), wholesalers (Q4 2026), manufacturers (Q1 2027). (gs1us.org)
• On‑chain notarization for EPCIS events: store event digests, trading‑partner DIDs, and DSCSA verification responses; support dispute resolution with cryptographic evidence (no product data on chain).
• Verification and alerts: when a saleable return’s product identifier fails verification, automatically raise a workflow with an immutable audit trail.

Benchmarks and precedents:

• The MediLedger FDA pilot (25 companies) demonstrated decentralized change‑of‑ownership concepts meeting DSCSA’s interoperability goals; several industry networks have since operationalized blockchain for traceability. Use these learnings to require privacy‑preserving interoperability (zero data leakage across competitors). (mediledger.com)

RFP asks:

• Evidence of GS1 EPCIS test harnesses and conformance trustmarks; integration experience with leading DSCSA platforms. (prnewswire.com)
• A plan for handling the staggered FDA exemptions (through Nov 27, 2026 for small dispensers) without disrupting fulfillment. (fda.gov)

---

4) Provider identity, credentialing, and directory accuracy

What changed:

• W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on May 15, 2025—maturing the standards stack for verifiable provider credentials and status lists. DIDs have been a W3C Recommendation since 2022. (w3.org)
• The industry is moving from static directories to FHIR‑based Plan‑Net and national endpoint directories. CAQH’s Endpoint Directory transitioned to Edifecs management on Feb 1, 2025—relevant for connecting to payer endpoints. (caqh.org)

Where blockchain adds value:

• Provider credential VC issuance/verification: medical license, DEA, board cert, network participation as Verifiable Credentials; maintain a revocation/status list on chain; present credentials to automate onboarding. (w3.org)
• Shared provider directory governance: Synaptic Health Alliance’s multi‑payer blockchain showed collaborative directory maintenance can reduce redundant outreach; use that model—plus Plan‑Net—to drive measurable accuracy. (Note: ROI claims are from participant testimonials.) (synaptichealthalliance.com)

RFP specifics:

• Require Plan‑Net 1.2 profiles and FHIR endpoint discovery integration; specify VCDM 2.0 credential formats and status list method; map roles/rights to prevent PHI exposure during directory sync. (hl7.org)

---

5) Consent, provenance, and privacy‑preserving analytics

Must‑haves:

• Consent registry with cryptographic proofs: record consent intent and scope on chain; store consent artifacts off‑chain; link each data exchange to a consent hash; expose machine‑verifiable proofs to auditors.
• FHIR Provenance and AuditEvent first: every read/write/search event should generate AuditEvent, while content generation/updates attach Provenance; anchor their hashes to a ledger for integrity. (hl7.org)
• Zero‑knowledge verification patterns: use ZKPs to prove policy compliance (e.g., “only SDOH elements shared”) without exposing raw data; start with pilot‑grade circuits for high‑value checks; keep PHI off‑chain.

KPIs to track:

• % of API calls with attached verifiable consent proofs
• Mean time to produce audit evidence (target sub‑minutes via on‑chain references)
• % of provenance‑linked resources (goal ≥95%)

---

6) Security engineering: CSF 2.0 and post‑quantum planning baked in

What to require:

• CSF 2.0 alignment, with explicit coverage of the new Govern function (roles, risk strategy, supply‑chain risk) and ledger node hardening; use the CSF 2.0 reference tool to map outcomes to controls. (nist.gov)
• Post‑quantum crypto roadmap: vendor must show how keys, signatures, and TLS will migrate to NIST PQC (FIPS 203/204/205). For 2025–2027, require hybrid approaches (classical + PQ) and inventory of cryptography used by smart contracts, API gateways, and client SDKs. (nist.gov)
• Secrets and key custody: support HSMs, threshold/MPC for validator keys, and rotation policies tied to clinical change‑management windows.

---

7) Reference architectures that work in healthcare

• Anchor‑only pattern (regulated data off‑chain):
  • PHI, FHIR, EPCIS stay in your systems; the ledger stores hashes, timestamps, DIDs, and minimal metadata; ideal for TEFCA, CMS APIs, DSCSA notarization.
• Consortium permissioned network:
  • Hyperledger‑style network among payers/IDNs life‑sciences; each member runs a node; shared smart‑contract governance for provider directory, consent registries, or supply‑chain disputes.
• Hybrid public‑permissioned:
  • Enterprise chain for daily ops; periodic checkpoints to a public PoS chain for broad transparency and anti‑tamper guarantees (no PHI). Choose PoS or permissioned BFT to minimize energy/cost.

What to test:

• Throughput: prove you can notarize 100% of API calls (peaks) without adding patient‑visible latency.
• Evidence recall: retrieve a complete audit trail (API request→Provenance→AuditEvent→on‑chain anchor) within service‑level targets.

---

8) RFP checklist: precise asks that separate vendors

Interoperability and policy

• TEFCA: show message flows for “facilitated FHIR,” QTF v2.x conformance, and delegation model; roadmap to QHIN‑to‑QHIN FHIR. (sequoiaproject.org)
• CMS‑0057‑F: list which FHIR guides you implement (PDex, CRD, DTR, PAS); confirm Jan 1, 2027 API readiness and 2026 metrics reporting; explain HIPAA enforcement discretion approach for FHIR‑only PA APIs. (cms.gov)
• Plan‑Net and endpoints: demonstrate integration with the national Endpoint Directory (now managed by Edifecs) and Plan‑Net 1.2 provider directory. (edifecs.com)

Supply chain

• DSCSA exemptions awareness and continuity plan through 2025–2026; EPCIS R1.2 conformance and R1.3 migration with validation tooling. (fda.gov)

Identity and credentials

• VCDM 2.0 credential formats, status list design, and DID method(s) supported; revocation latency guarantees. (w3.org)

Security

• CSF 2.0 mapping (esp. Govern); PQC transition plan aligned to FIPS 203/204/205; documented key‑management workflows. (nist.gov)

Evidence and SLAs

• Guaranteed max audit‑evidence retrieval time; evidence schema including consent hash, operation ID, and FHIR resource references.

---

9) Emerging best practices we’re seeing win in 2025

• Keep data models native: FHIR and EPCIS remain your system of record; the ledger is for proofs and policies, not payloads. This simplifies TEFCA and CMS audits and reduces HIPAA surface area. (hl7.org)
• Use W3C credentials for people and organizations: issue verifiable credentials for licensure, network participation, and device attestation; maintain revocation lists on chain; avoid “phone‑home” checks that leak data. (w3.org)
• Model consent like a contract: hash the consent document, include scope, purpose, and expiry; reference that hash from each API call’s AuditEvent; auditors verify with a single query. (hl7.org)
• Design for mixed standards during transition: expect some partners on X12 or CSV and others on FHIR/EPCIS; include adapters but notarize everything uniformly on chain. (cms.gov)
• Govern like you mean it: adopt CSF 2.0’s Govern function in your consortium rules—who can deploy contracts, rotate keys, and respond to incidents; align with vendor risk management. (nist.gov)

---

10) Two concrete service blueprints you can drop into an RFP

Blueprint A: Prior Auth transparency + audit in 120 days

• Scope: PAS/CRD/DTR integration; FHIR‑only PA supported; notarize each PA step on chain; patient‑facing status via Patient Access API.
• Deliverables:
  • FHIR gateway with CMS‑0057‑F APIs, SMART/OIDC setup. (cms.gov)
  • Smart contracts for PA lifecycle (request→clinical doc→decision); off‑chain store for artifacts; on‑chain proof registry.
  • Auditor dashboard: filter by member ID, time, facility; one‑click retrieval of consent and AuditEvent chain. (hl7.org)

Blueprint B: DSCSA EPCIS notarization + dispute resolution in 16 weeks

• Scope: EPCIS 1.2 exchange with conformance tests; on‑chain anchors of commissioning/aggregation/shipping events; automated dispute workflows.
• Deliverables:
  • EPCIS event capture/services; GS1 R1.2 conformance report with R1.3 migration path/schedule (dispenser→wholesaler→manufacturer). (gs1us.org)
  • Smart contracts for event hash registry and dispute case tracking; API to verify event integrity during investigations.
  • SLA playbook for enforcement/exemption periods through 2025–2026 (role‑specific). (fda.gov)

---

11) What good looks like: measurable outcomes to include

• Interoperability: ≥99.9% of TEFCA exchanges and CMS‑mandated API calls logged with verifiable proofs; endpoint discovery automation via national directory. (edifecs.com)
• Supply chain: ≥99% of EPCIS events anchored within 5 minutes of capture; dispute Mean Time to Resolution reduced with cryptographic evidence. (gs1us.org)
• Security: CSF 2.0 profile in place; quarterly cryptography inventory and PQC pilot using hybrid KEM/TLS for internal service hops. (nist.gov)

---

Final take

Blockchains are not a magic EHR or a new DSCSA system—but they’re excellent at verifiable evidence, shared state, and cross‑org governance. Anchor your RFP in the 2024–2027 rulebook: TEFCA’s FHIR pathway, CMS‑0057‑F’s APIs, DSCSA’s EPCIS adoption path, and NIST’s CSF 2.0/PQC. Then ask vendors to show exactly how their ledger components reduce audit burden, automate trust in identity and consent, and harden your supply chain—without putting PHI on chain. (sequoiaproject.org)

---

Sources (selected)

• TEFCA Common Agreement v2.x, QTF v2.0, and FHIR roadmap updates. (sequoiaproject.org)
• CMS‑0057‑F (Interoperability & Prior Auth) deadlines and enforcement discretion. (cms.gov)
• DSCSA stabilization/exemption dates and EPCIS adoption guidance. (fda.gov)
• NIST PQC FIPS (203/204/205) and CSF 2.0. (nist.gov)
• W3C VCDM 2.0 Recommendation and DIDs. (w3.org)
• Provider directories and endpoint discovery (Plan‑Net, Edifecs/CAQH). (hl7.org)
• HL7 FHIR AuditEvent and Provenance patterns. (hl7.org)

---