For customers operating in regulated environments or in partnerships with regulated entities, the De-Identification Logging Service provides improved support for the management of patient data by providing a way for customers to re-identify data when necessary. For example:
As part of the “Right to be Forgotten” (GDPR)
If a subject withdraws consent to participate in study or clinical trial
If there are subject health concerns
The service automatically logs all de-identified personal information for incoming DICOM data and posts it to a customer provisioned database. Querying the log allows customers to identify the subject’s data in Flywheel and take the appropriate actions.
This article gives an overview of how the De-identification Logging Service works, steps for configuring the service, and how to search for data.
Warning
The de-identification logging service is an add-on feature. Contact your Flywheel account manager to purchase the service for your Flywheel site.Enabling the de-identification service should not significantly impact upload speed
The service is enabled at the site level. This means that it applies to all projects.
You are responsible for any re-identification measures. Flywheel cannot access your de-identification logs
The service also supports saving the logs locally
There are two deployment options for the logging service:
Use the SQLite database on your Flywheel instance's Kubernetes cluster.
Use your own infrastructure. This means you are responsible for ensuring that the service is up and running.
If you are maintaining your own infrastructure, you are responsible for hosting and managing the service and the PHI within the logs.
The De-Identification Logging Service supports using the following databases:
SQLite
Postgres
MySQL
After you have chosen to either host the service on your own infrastructure or on your Flywheel deployed cluster, provide Flywheel Support with the Host/IP and the port number.
Note
Flywheel uses this information to update the configuration of all Flywheel upload methods like the CLI, device connectors, and web uploaders. This means no matter how users get data into Flywheel, the de-identified information is logged.
In general, once the service is configured, you won't see much difference in your Flywheel environment. However, if your de-identification logging service is down, you will not be able to upload any data to Flywheel until it is back up.
When data is successfully posted to the de-identification logging service, a de-id log id is returned. This ID is written to the imported file’s metadata in Flywheel. See the schema below for the default DICOM tags that the logging service.
There are two ways to query data:
By using the DICOM tags
By using the de-id log id
This allows SQL queries that key on DICOM tags, which include personally identifiable information, in the PHI log to return a set of IDs that can be cross-referenced to locate relevant data in Flywheel.
sqlite> SELECT id FROM deid_log WHERE PatientName = ‘John Doe’
Field |
Type |
Description |
|---|---|---|
id |
BINARY(16) NOT NULL |
Primary Key |
AccessionNumber |
VARCHAR(16) |
DICOM Tag |
PatientBirthDate |
VARCHAR(8) |
DICOM Tag |
PatientID |
VARCHAR(64) |
DICOM Tag |
PatientName |
VARCHAR(512) |
DICOM Tag |
StudyInstanceUID |
VARCHAR(64) |
DICOM Tag |
StudyID |
VARCHAR(16) |
DICOM Tag |
StudyDate |
VARCHAR(8) |
DICOM Tag |
StudyTime |
VARCHAR(16) |
DICOM Tag |
StudyDateTime |
VARCHAR(26) |
DICOM Tag |
StudyDescription |
VARCHAR(64) |
DICOM Tag |
SeriesInstanceUID |
VARCHAR(64) |
DICOM Tag |
SeriesDate |
VARCHAR(8) |
DICOM Tag |
SeriesTime |
VARCHAR(16) |
DICOM Tag |
SeriesDateTime |
VARCHAR(26) |
DICOM Tag |
SeriesDescription |
VARCHAR(64) |
DICOM Tag |
TimezoneOffsetFromUTC |
VARCHAR(16) |
DICOM Tag |
DeidentifiedTags |
JSON NOT NULL |
Serialized JSON of all removed or modified DICOM tags. |