DICOMweb is the standard that moves medical images today, and W3C is still advancing decentralized identity. Blockchain gets pitched as the layer between them, but it brings real problems with privacy, immutability, key recovery, cost and governance. Here is the build order we recommend.
Two different conversations
"DICOM and blockchain" and "decentralized identity" tend to get pitched as one idea. They are different technologies with different jobs. DICOM is how medical images and their metadata are stored, moved and displayed: radiology, cardiology, ophthalmology and now whole slide images in digital pathology. Decentralized Identifiers (DIDs) are a W3C standard for identifiers that a person or organization controls without a central registry, usually paired with verifiable credentials. The first carries clinical content. The second proves who someone is or what they are entitled to. Neither one needs a blockchain, and the case for adding one is narrower than most pitches suggest.
DICOM in 2026: still the floor, now on the web
DICOM is not standing still. The standard is revised several times a year, and its web services part, DICOMweb (PS3.18), is where most new imaging integrations are built:
- QIDO-RS to search for studies, series and instances over HTTPS.
- WADO-RS to retrieve them, including rendered frames for zero-footprint browser viewers.
- STOW-RS to store them, so a modality gateway, AI service or outside facility can push images without a DIMSE association.
- UPS-RS for worklists, so AI and post-processing steps can be orchestrated as tasks instead of folder watchers.
DICOMweb is what lets an EHR link to images through a FHIR ImagingStudy resource, a viewer open a study without a local client, and a cloud or vendor-neutral archive serve several sites. It also covers whole slide imaging, which matters for any lab moving to digital pathology: a DICOM-native slide is one more study in the same archive instead of a proprietary file on a scanner share.
What breaks first in real deployments is rarely the standard. It is the plumbing around it: inconsistent patient and accession identifiers across sites, archives that answer QIDO slowly once they hold millions of instances, viewers that fail when a study has not finished arriving, and authentication bolted on after the fact. Pathology adds its own: whole slide images are large enough that converting them, moving them off site and feeding them to AI becomes a capacity problem for storage, the WAN and the conversion queue. Those are the problems that decide whether imaging works in 2026.
"DICOM-compliant" is a claim, not evidence
Most digital pathology scanners write their own file formats, and many vendors now offer DICOM output by converting or wrapping them. The base standard allows a thin wrapper, and a thin wrapper can drop exactly what pathology depends on: illumination, color profile, optical density and pixel spacing. You cannot see the difference by opening a slide. The viewer renders, and the AI that measures cells or reads stain intensity quietly gets it wrong.
DICOM writes the standard but has no one enforcing it. Pathology integration profiles close the gap by making those otherwise optional fields mandatory for anyone who claims to conform, and IHE Connectathons are where the claims get tested: archives, viewers and scanners exchange real objects and reviewers check that what a vendor claims is actually there. Before you buy, ask for the evidence:
- Connectathon results for the exact product and version.
- A conformance statement that names the pathology profile, so you know which fields the vendor commits to fill in.
- Sample DICOM files made from your own slides, checked field by field.
- The size of converted files against the originals: conversion without extra processing can make files much larger, and that multiplies storage and network cost at whole-slide scale.
- Identifier handling: whether patient ID, accession number and study and series UIDs survive conversion. If they do not, the link between a slide and its patient depends entirely on a crosswalk kept somewhere else, and that crosswalk becomes a patient-safety system.
- A round trip: scanner to archive to viewer to analysis tool, on your network. File validity is not interoperability.
Conversion is also a custody event. Wherever it happens, at the scanner, on an edge server or in a vendor's cloud, it needs sizing, monitoring of its queue and a check that identifiers and metadata come out the other side intact, every time the scanner firmware or the converter changes.
Decentralized identity: promising, and mostly about credentials
W3C keeps advancing this work. DID Core 1.0 has been a W3C Recommendation since July 2022, the Verifiable Credentials Data Model 2.0 became a Recommendation in May 2025, and DID 1.1 reached Candidate Recommendation in March 2026. The most practical healthcare uses are not about images at all:
- Clinician credentials: a license, board certification or privileging decision issued as a verifiable credential that another facility checks in seconds instead of weeks.
- Organization identity: proving that a request really comes from a given hospital, lab or payer.
- Patient-held proofs: insurance eligibility or consent that a patient presents without exposing the rest of their record.
Some DID methods anchor to a blockchain; many do not (did:web, for example, uses an ordinary web domain). Choosing decentralized identity does not commit you to a ledger. It also does not solve the identity problem imaging teams lose sleep over, which is knowing which patient a slide or study belongs to. That is an accession and UID crosswalk, and it has to be checked wherever images are converted or moved.
Where blockchain breaks in healthcare
Ledgers solve one specific problem: several parties who do not trust a single operator need to agree on a shared record that none of them can quietly rewrite. Healthcare data runs into five problems with that model:
- Patient privacy. Protected health information must never go on a ledger, and even hashes and identifiers can be linked back to a patient when they are replicated to every participant. In practice the clinical data stays off-chain and the ledger holds pointers and fingerprints, which leaves most of the hard problems where they were.
- Immutable records. HIPAA gives patients a right to request amendments, GDPR adds a right to erasure, and records are corrected every day. A ledger that cannot forget has to be designed around that from day one, usually by appending corrections and keeping anything personal off-chain.
- Key recovery. If access depends on a private key, a lost phone or a departed administrator can mean lost access. Every workable recovery scheme brings back a trusted party, which is the thing the ledger was meant to remove.
- Operating costs. Nodes at every member, consensus, upgrades, monitoring, security reviews and the people to run them. That cost is ongoing, and it is usually larger than the database it replaces.
- Governance between hospitals. Who admits and removes members, who approves upgrades, who is liable when a record is wrong, and what happens when a member is acquired or leaves. These are contracts and committees, not code, and they take longer than the technology.
What to build first
Our recommendation: start with DICOMweb, FHIR, signed provenance records and conventional access controls. Together they deliver most of what a blockchain is pitched to deliver, with tools your teams and vendors already support.
- DICOMweb for imaging exchange, behind an authenticated gateway, with one identifier strategy across sites and conformance proven rather than assumed.
- FHIR (ImagingStudy, DiagnosticReport, Provenance) to tie images and results to the patient record, with SMART on FHIR and OAuth 2.0 for application access.
- Signed provenance: DICOM digital signatures and FHIR Provenance resources record who created or changed what, and when. An append-only, hash-chained audit log, published to partners if needed, makes tampering detectable without a consensus network. This is the same approach Certificate Transparency uses to keep the web's certificate authorities honest.
- Conventional access controls: role-based access, multi-factor authentication, encryption in transit and at rest, and audit trails your compliance team can actually read. The HIPAA Security Rule update HHS proposed in December 2024 points the same way; it had not been finalized when we last checked, but none of it is worth waiting for.
Put together, it looks like this. Slides in vendor formats are converted and checked before they reach the archive, and the archive stays the single source of truth for images: AI reads over DICOMweb and writes its results back as DICOM objects, so a finding never lives only in a vendor's cloud. Provenance, audit and identity are not a box beside the AI; they cover every step.
When a permissioned ledger earns its place
Add a permissioned blockchain only when multiple independent institutions genuinely need a shared trust layer and there is no single operator they will all accept. A simple test before anyone writes a smart contract:
- Are there at least three independent organizations writing to the same record?
- Have they rejected every candidate operator: a health information exchange, a TEFCA participant, a vendor or one of the members?
- Would a signed, publicly verifiable log fall short of what they need?
- Does all patient data stay off the ledger?
- Have the members agreed in writing on governance, liability, onboarding and exit?
If any answer is no, a ledger adds cost and risk without adding trust. If all five are yes, a permissioned network, layered on the same DICOMweb, FHIR and provenance foundation, can be the right tool.
A phased path
- Inventory: every modality, scanner, archive, viewer, interface engine and identity source, with an owner for each.
- Prove conformance before you buy: run your own sample files through a test lab (an open-source archive and viewer such as Orthanc and OHIF both handle pathology slides) and collect the evidence listed above.
- Standardize exchange: conversion sized and monitored at the edge, DICOMweb in front of the archive, FHIR ImagingStudy links in the EHR, one patient and accession identifier strategy.
- Prove integrity: signed provenance and tamper-evident audit logs, with monitoring that flags stale or missing data instead of hiding it.
- Pilot identity: verifiable credentials for clinician onboarding or partner organizations, where the payoff is fastest.
- Evaluate a ledger: only when the five-question test passes, and only on top of the foundation above.
Steps two and four do not end. Rerun the sample-file check after every scanner firmware, converter or archive upgrade: a change that quietly drops a field changes every result that depends on it.
Get the readiness pack
The evidence list above, a readiness lab outline for testing your own slides before you buy, a conversion and egress sizing worksheet and this article's architecture drawing, as one PDF. Request the DICOM Pathology Readiness Pack: it is free and arrives by email after a short review.
Where we come in
CarolinaEMR, part of PazNetworks, designs and supports the infrastructure and integrations under clinical imaging and digital pathology: networks, storage and archives, DICOMweb and FHIR interfaces, identity and access, and the monitoring that proves the whole chain is working. See our Chain of Custody program, our digital pathology delivery playbook and digital pathology explainer, or talk to us about your imaging roadmap.
Published October 17, 2026. Standards status as of this date: DID 1.1 is a W3C Candidate Recommendation, and the proposed HIPAA Security Rule update had not been finalized; check the W3C and the Federal Register for current status. This article is general information, not legal or compliance advice. DICOM is a registered trademark of NEMA; HL7 and FHIR are registered trademarks of Health Level Seven International.
