P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Sector specialist

Clinical imaging and healthcare IT

PACS, RIS and HIS estates I ran for eight years: DICOM and HL7 integration, migration off ageing archives, and securing imaging kit designed before anyone assumed it would be on a network.

DICOM was published in 1993 for a trusted, isolated network, and its defaults still assume one: services that answer to whoever reaches the port, authentication that is optional and usually unused. Then the estate was networked, given a web viewer and joined to a national record. Nothing here is a vulnerability in the usual sense: it is a protocol working exactly as designed, in an environment it was never designed for.

1993

DICOM first published

Designed for a trusted, isolated network. The defaults still assume one.

8

Years running this estate

PACS, DICOM, HL7, HIS and RIS in live clinical environments, 2010 to 2018.

2

HL7 generations, usually at once

v2 interfaces and FHIR running side by side. The older one holds the surprises.

3

Places identifiers hide in an export

Metadata, vendor private tags, and annotation burned into the pixels.

What it covers

DICOM

Storage, Query/Retrieve, Modality Worklist, Storage Commitment. Association negotiation, called and calling AE titles, and whether anything actually verifies them.

HL7 v2 and FHIR

ADT feeds, order and result interfaces, and the integration engine in the middle. Most estates run both generations at once and the older one is where the surprises are.

IHE profiles

Scheduled Workflow, PIX and PDQ, XDS-I. The profiles are how you tell an integration problem from a configuration problem.

DSPT and NHS assurance

The Data Security and Protection Toolkit, and the evidence an imaging estate is expected to produce for it.

Network segmentation

The control that actually works here, because much of the estate cannot be patched on any schedule you control.

UK GDPR and de-identification

Pixel data is only half the problem. Burned-in annotation and the private tags are where identifiers survive an export that everyone believed was anonymous.

How the work runs

  1. 1

    Survey the estate as it is

    Modalities, archive, worklist, viewers, gateways and routing rules, including the interface somebody stood up for a research project in 2019 and never decommissioned. The documented architecture and the running one are rarely the same.

  2. 2

    Map the flows

    Every DICOM association and HL7 interface, in both directions, with the AE titles and endpoints that actually appear on the wire rather than the ones in the design document.

  3. 3

    Assess against clinical reality

    Separate what can be segmented this month, what needs a maintenance window, and what waits for a modality refresh. A recommendation that requires downtime you cannot take is not a recommendation.

  4. 4

    Test the de-identification

    Against real exports rather than the configuration. Burned-in annotation and private tags survive most pipelines that are believed to be safe.

  5. 5

    Plan the migration, if there is one

    Study integrity and prior availability as acceptance criteria, with a rollback that has been thought through before the first study moves.

  6. 6

    Hand over something operable

    Documentation and a control set your own team runs afterwards, not a report that needs the author present to be useful.

What you walk away with

  • An imaging estate map: modalities, archive, worklist, viewers, gateways and every route in and out
  • A DICOM and HL7 interface inventory with the AE titles, endpoints and trust assumptions on each
  • A segmentation plan sequenced by what is achievable without clinical disruption
  • A de-identification test result against real exports, covering metadata, private tags and burned-in annotation
  • Migration acceptance criteria written around study integrity and prior availability
  • An operating handover: runbooks and a control set your team maintains without the consultant

Where this sits against clinical governance

This is delivery experience rather than framework knowledge, which is the distinction that matters on this page: the estate described here is one I ran for eight years. What still belongs to you is clinical sign-off. Your Clinical Safety Officer owns the safety case and your information governance lead owns the disclosure decisions. What this brings is the ability to tell them precisely how the systems behave, which is usually the part nobody can answer.

What I bring

  • The technical picture of how imaging actually flows through your estate
  • Segmentation and hardening sequenced against clinical availability
  • Interface and migration planning with testable acceptance criteria
  • Evidence in the form DSPT and internal audit expect

Stays with you

  • Clinical safety sign-off, which belongs to your named Clinical Safety Officer
  • Decisions about disclosure and lawful basis, which belong to information governance
  • Vendor contractual remedies where a modality cannot be secured
  • The change control calendar, because clinical availability is your call and not mine

How this plays out

Example scenario

An imaging estate believed to be isolated from the wider network.

The work: Traced every DICOM association and HL7 interface actually in use, rather than reading the architecture diagram.

The archive was reachable from general corporate network segments through a viewer gateway nobody had listed as an interface.

Example scenario

A research export described as fully anonymised.

The work: Inspected real exported studies rather than the de-identification configuration.

Pixel data was clean and the profile was correct. Burned-in annotation on one modality and a vendor private tag both carried identifiers straight through.

Example scenario

A trust planning to retire an ageing archive.

The work: Migration planning with prior availability as an explicit acceptance criterion.

The cutover plan had no defined position on what happens to a radiologist requesting a prior mid-migration, which is the failure mode that turns a migration into an incident.

Start the conversation

A question about this area, an invitation to speak, or a role you think fits: write, and you will get a straight answer.

Get in touch

Share this

Send it to whoever owns the budget or the risk.

← All areas

The problem

Clinical imaging is the part of healthcare IT that generalist security consultants get wrong, because the constraints are not the ones they are used to.

DICOM was published in 1993 and designed for a trusted, isolated network. Its defaults reflect that: services that answer to anyone who can reach the port, authentication that is optional and frequently unused, and an association model where the reasonable assumption is that everything on the wire belongs there. Then the estate was connected to a wider network, given a web viewer, and joined to a national record.

Nothing about that is a vulnerability in the usual sense. It is a protocol working as designed, in an environment it was never designed for. The published research on exposed imaging archives, and the guidance the US Department of Health and Human Services has issued on PACS exposure, is what happens when that gap is left alone.

Meanwhile the clinical constraint is absolute. You cannot take the archive down for a weekend, you cannot break the modality worklist, and a radiologist who cannot pull a prior is a patient safety issue, not a service ticket.

What you get

  • A survey of the imaging estate as it actually is: modalities, archive, worklist, viewers, gateways, routing rules, and every route in and out that somebody added and did not document
  • DICOM and HL7 integration reviewed end to end, including the interfaces that were built once and never revisited
  • A security assessment written for clinical reality: what can be segmented now, what needs a maintenance window, and what has to wait for a modality refresh
  • Migration planning that treats the archive as the asset it is, with study integrity and prior availability as the acceptance criteria rather than an afterthought
  • Data protection work on the imaging-specific questions: what is in the metadata, what leaves in a research export, and whether de-identification actually de-identifies
  • Documentation your own team can operate from once the work ends

Proof point

Eight years running exactly this environment, from 2010 to 2018: PACS, DICOM, HL7, HIS and RIS implementation, vulnerability management and security audit across live clinical systems, and training clinical staff to operate them safely. The healthcare AI assurance practice grew out of it, which is why the questions here start with how the estate behaves rather than with a control framework.