Skip to content
Blimdata

Security & compliance

PHI never leaves the hospital network.

The de-identification step runs inside the hospital, in the same process that reads the PACS. Re-identifiable data is never transmitted, never staged in our cloud and never held by us — not as a matter of policy, but as a matter of where the software executes.

  • De-identification standard

    HIPAA Safe Harbor — all 18 identifiers.

  • Pixel data

    Burned-in text detected and redacted separately.

  • Encryption

    AES-256 at rest · TLS 1.3 in transit.

  • Access & audit

    Role-based, least privilege, append-only logs.

Architecture

PHI never leaves the hospital.

The gateway that reads your PACS is the same process that strips the identifiers. Re-identifiable data is never transmitted, never staged in our cloud, and never held by us — because the de-identification step runs before anything touches the wire.

This is not a policy setting that somebody could switch off. It is where the software runs.

NDPA aligned AES-256 at rest TLS 1.3 in transit RBAC Immutable audit log
Data boundary
Inside hospital network
Hospital PACS Source of truth
Blimdata gateway Read-only DICOM
De-identification 18 PHI identifiers
Blimdata cloud
Annotation workspace Radiologist review
Quality control Adjudication
Licensed data room Versioned · audited

De-identification

The 18 identifiers. All of them, every time.

DICOM headers carry far more identity than most people expect. Each of the following is removed, replaced or generalised before a study is eligible to leave the hospital network.

  • Patient names, including referring and reading physician name fields
  • Geographic subdivisions smaller than a state, including addresses and postcodes
  • All date elements more precise than a year, including study, birth and admission dates
  • Telephone numbers held in patient or institution fields
  • Fax numbers
  • Email addresses
  • Social security or national identification numbers
  • Medical record numbers
  • Health plan beneficiary numbers
  • Account numbers
  • Certificate and licence numbers
  • Vehicle identifiers and serial numbers, including licence plates
  • Device identifiers and serial numbers, including scanner serial numbers
  • Web URLs held in any tag
  • IP addresses recorded by acquisition or routing systems
  • Biometric identifiers, including finger and voice prints
  • Full-face photographic images and comparable images
  • Any other unique identifying number, characteristic or code, including private tags

Dates are shifted consistently per pseudonymous subject rather than simply deleted, so temporal relationships between a subject’s studies survive de-identification. Private and vendor-specific tags are handled explicitly by allow-list — never passed through by default.

Beyond the header

Header cleaning is not enough.

A scan can carry a patient name burned directly into the image pixels — an ultrasound annotation, a scanned film, a secondary capture. A pipeline that only cleans metadata will publish that name at full resolution. Ours looks at the picture.

  • Every study is scanned for burned-in text regardless of what the header claims.
  • Detected regions are redacted in the pixel data before the study is eligible for transfer.
  • A validation pass re-scans the de-identified output rather than trusting the first result.
  • Studies that still trip a rule are quarantined inside the hospital network for local review.
  • Quarantine is the default outcome for ambiguity — a study is never released on a maybe.
Validation gate
Header de-identification 18 identifiers
Pixel text detection Full-image scan
Redaction In pixel data
Re-validation Independent second pass
Release or quarantine Ambiguity → quarantine

Only studies that clear re-validation cross the network boundary.

Platform controls

What protects the data once it is ours to hold.

De-identified data still deserves real controls. These are the ones a licensee’s security review asks about.

Encryption

AES-256 · TLS 1.3

AES-256 for data at rest across storage and backups; TLS 1.3 for all data in transit, including the gateway’s outbound connection and every data-room access.

Access control

Role-based, least privilege

Annotators, reviewers, hospital administrators and licensees hold distinct roles scoped per dataset. Access is granted deliberately and expires with the agreement that justified it.

Audit

Immutable logging

Reads, exports, permission changes and administrative actions are written to an append-only log. Logs support both compliance reporting and hospital revenue attribution.

Segregation

Isolated environments

The annotation environment and the licensed data room are separate, with no path from a licensee’s access to raw pipeline internals or to another licensee’s scope.

Residency

Regional data residency

Storage region is configurable per dataset to satisfy licensee and partner-institution requirements. Residency is fixed in the agreement, not adjusted silently.

Governance

Hospital remains controller

Source institutions retain data-controller status for their archives, define scope in writing, and hold audit rights over what was processed and released.

Regulatory posture

Nigerian law.International usability.

The pipeline is built to the Nigeria Data Protection Act. Partner hospitals remain the data controller for their own archives, define processing scope in a written agreement, and can suspend or withdraw participation.

De-identification follows the HIPAA Safe Harbor method rather than a local minimum, because a dataset is only commercially useful if a US or EU licensee can also rely on it. Meeting the stricter standard once is cheaper than reconciling two.

We do not claim certification we do not hold, and we will not tell your counsel that our compliance removes your obligations. What we provide is a documented, auditable chain — the de-identification method, its validation result, the provenance record and the access log — for your own review to work from.

Compliance you cannot evidence is a marketing claim. Compliance you can reconstruct from a log is a control.

Security questions

What security teams ask.

Does the gateway require inbound network access?

No. It establishes outbound TLS 1.3 connections to a fixed endpoint that your team can allow-list. There are no inbound ports, no listening services exposed to the internet, and no VPN tunnel to maintain.

Can the gateway modify or delete anything in our PACS?

No. It operates under a read-only application entity title using standard DICOM query and retrieve. It has no write path to your archive, by configuration and by capability.

What happens to a study that fails de-identification?

It is quarantined inside your network and never transmitted. Quarantine is the default outcome whenever validation is ambiguous, so the failure mode is a study that does not get licensed rather than a study that leaks.

Do you re-identify data under any circumstances?

No. We hold no re-identification key and have no mechanism to reverse the process. Where longitudinal linkage is required, studies are linked under a pseudonymous subject identifier that maps to nothing outside the source institution.

Can our security team review the pipeline directly?

Yes. We provide a technical brief covering the gateway, network posture, de-identification method and validation approach, and we will walk your security team through it under NDA as part of diligence.

How long is data retained?

Retention is defined in the agreement with the source institution and, separately, in each licence. Both are explicit terms rather than defaults, and expiry is enforced by access control rather than by policy alone.

Send it to your security team.

We will provide the technical brief, walk your engineers through the pipeline, and answer diligence questions in writing.