Proposal for a set of APIs to support updating of DICOM instances via DICOMweb

Status: Requesting feedback from community Last Update: Jun 11, 2024

• Synchronize attributes shared with EHR/RIS (Patient name/id/gender/dob, study description, procedure code)
  • Change patient name for all of a patients studies
  • Change patient name for patient studies only after they were married (preserve maiden name in DICOM)
• De-identify data
• QC Workflows
  • correct fat fingered data (patient name, patient id) so it will reconcile with the EHR/RIS
  • Correct data imported from third party so it will reconcile with the EHR/RIS (e.g. foreign images)
  • delete bad data (e.g. patient moved)
  • merge two studies together (e.g. time delayed studies)
  • move instances from one study into another study (e.g. procedure was not completed on scanner before second patient was scanned)
• Modernize data (e.g. remove private attribute with custom annotations and create new presentation state instance with those annotations)
• Changing the transfer syntax of stored sop instances (transcoding)

All APIs will use standard HTTP status codes as defined by the DICOM standard

For systems that do not enforce unique identifiers (e.g. PatientID, StudyUID, SeriesUID, SOPInstanceUID) additional attributes may be passed using DICOM specific custom HTTP Headers.

These APIs allow you to replace, update and get subsets of DICOM data. The allowed subsets are the patient, study, series and instance level as defined by the DICOM standard in PS3.3 C.7. These would be used by most of the use cases listed at the top of this document. All private attributes are considered instance level attributes. ETAG is used to detect and prevent update conflicts.

• GET
• PATCH (update)
• PUT (replace)

This API allows you to update one or more instances in a study or series. This can be useful for updating instance level attributes for multiple instances at a time (e.g. removing private attributes)

• PATCH (update)

These APIs allow you to "reparent" a study, series or instance. This can be useful for merge/split use cases. Note that the instances are not copied or cloned, they are moved. After the move is complete, the instance are no longer available via the prior resource paths.

Move APIs

These APIs allow you to permanently delete a patient, study, series or instance

Delete APIs

• Q: Why did you introduce a normalizedmetadata endpoint?

  • A: The existing metadata endpoints return all metadata for all instances at that level (study, series) which can be very large (>10GB for large studies). Each instance returned has patient/study/series attributes which may not be consistent. Most update/replace use cases only effect a few attributes so working with a smaller document is easier and avoids conflicts related to shared data at the patient/study/series levels.

• Q: How would you merge two patients?

  • A: Use Move Study to move all studies from patient A to patient B. See the unit test "should move patient 2s images from patient 1s study (split use case). Assumes patient 2 already has a study in the db"

• Q: Is there a way to update attributes at different levels with a single atomic operation?

  • A: Yes, see the Metadata Update/PATCH APIs

• Q: Why did you break out patient attributes separate from study attributes?

  • A: One of the most common update operation is to synchronize patient level attributes with an external system (EHR/RIS). The patients endpoint allows this change to be atomically for all studies associated with a single patient. Since a patient could have 100's of studies, it is more efficient to have one operation that updates all studies for a patient than requiring the client to make calls for each study. It also ensures consistency of patient data between all of the patients studies

• Include the IssuerOfPatientId as part of the patient resource key somehow?