Since we announced de-identification as a featured module in the Unifier Enterprise Imaging platform, we have received a slew of questions on how we perform de-identification. We also had questions on what’s possible with de-identification and the methods and regulations around this process. We’ve compiled questions below that have come in from professionals like data scientists, senior robotics software engineers, product managers, and systems analysts.
What methods should be used to de-identify health information?
Two methods satisfy the HIPAA Privacy Rule’s deidentification standard: Expert Determination and Safe Harbor.
What types of images can be de-identified?
We can de-identify DICOM, XML, TIFF, pdf, among others.
What types of de-identification can your system perform?
Dicom Systems can remove pixel, mask-based, metadata, text removal from images. We reference an industry database of modalities based on vendor and model to find exact coordinates of where text was burnt into the medical image and mask that area.
What are the 18 identifiers required to comply with the HIPAA Privacy Rule?
- Address (all geographic subdivisions smaller than state, including street address, city county, and zip code)
- All elements (except years) of dates related to an individual (including birthdate, admission date, discharge date, date of death, and exact age if over 89)
- Telephone numbers
- Fax number
- Email address
- Social Security Number
- Medical record number
- Health plan beneficiary number
- Account number
- Certificate or license number
- Any vehicle or other device serial number
- Web URL
- Internet Protocol (IP) Address
- Finger or voice print
- Photographic image – Photographic images are not limited to images of the face.
- Any other characteristic that could uniquely identify the individual
If the needs for the research question changes in terms of demographics, dates, chronology of studies, do you redo the complete process?
The first step of identifying/filtering the studies to be pulled from the archive to be de-ID’d can be modified to include/exclude the input sample if processing as batches. How the input is de-identified is a very specific process detailed up front. It is good for your team to make every attempt to future-proof the design. That may mean adding in a provision to add a variable in the script to enable/disable a particular part of the logic. This is assuming that these variables are relatively simple and few. If there is a future need for a De-Id workflow that is a dramatic departure from the original design, i.e. adding in pixel anonymization where only DICOM metadata was explicitly defined previously, then, yes – new project. For example, with a current customer, we are using a user-defined table that they will manage to modify the QA process. Each project is unique and we’d need more information to make the determination.
What are the tools available to prevent DICOM data objects from leaving local private cloud and leak into shared cloud space where customers have access to data collected by our systems, i.e., images, timestamps, sensor readouts, etc… separation of salable and DICOM?
This falls under the implementation of HIPAA security rule Administrative, Physical, and Technical safeguards. How DICOM data is permitted to travel across networks, cloud-based or otherwise, is not unlike any other security provisions/management in your infrastructure. Access controls, security roles, application-level access controls, network firewall access rules, etc. This varies depending on the infrastructure in place. They need to define (identify cause) of the “leak” and address how to segregate/restrict access to the data. There are too many unknowns from this brief description. You should consult with their network and cloud administrators.