Categories
DICOM GDPR

DICOM explained Part 2: GDPR, Security and Personal Information – The Challenges with DICOM Data

In part 1 of our DICOM explained-series, you already learned that imaging plays an important role in modern medicine and that the focus is on files in DICOM format. You got to know what is behind the abbreviation DICOM, how it is used in healthcare, how a DICOM file is structured and that the DICOM headers and tags contain a lot of personal data. In part 2 of our DICOM series, we will go into detail about the latter and explain what problems the data contained can cause when working with DICOMs in practice.

Of course, it has many advantages that DICOM images contain a lot of technical and personal data (you don’t remember exactly which ones? Then go back and take a look into part 1 of our DICOM explained-series here). However, this is also problematic at the same time: If DICOMs are sent unencrypted by mail on a CD, for example – as it is still regularly done today, e.g., as part of a study or to obtain a second opinion – they can be directly assigned to the patient; and this is, of course, not in compliance with data protection laws. Who would want their neighbor to find out unintentionally that they suffer from a certain illness? Especially since the General Data Protection Regulation (GDPR) came into force in May 2018, there are many discussions and unknowns that lead to uncertainty among clinicians and healthcare workers who work with medical images. There are many aspects to consider, but here we will focus on personal identifiable data in DICOM images and its technical aspects.

DICOM data: Anonymization vs. pseudonymization

In this context, there are two terms that are often misused when talking about privacy protection of medical images. “anonymization” and “pseudonymization.” Anonymization means that there is no way to retrieve or identify the patient if you only have the medical images. Often physicians or study nurses use this term when informing the patient that “all data will be completely anonymized,” for example, in the context of clinical trials or eligibility testing by outside medical experts. However, the recipient of the images, a core lab or central reader, in most cases needs to know the date of the exam and from which location the images were sent, as these identifiers are an essential parameter of the clinical trial or project. Often, the purpose of a clinical project is to obtain a second opinion on a treatment recommendation, meaning it is imperative to match the right patient to the right images and verify the outcome. In these cases, the data is absolutely not anonymous. 

Is that a problem? No. But first, you would have to obtain written consent from a well-informed patient, and second, you would have to make sure that the data processor provides a technical and organizational GDPR-compliant environment. And if data must be shared for such a purpose, one should pseudonymize the data sets as much as possible. Pseudonymization means that identifying information (name, date of birth, etc.) is removed or replaced, reducing the possibility of tracing it back to the patient.

Where can I find personal information in DICOM data?

When viewing medical images with a DICOM viewer, one does not necessarily see the personal information immediately. As described above, a patient’s personal data, but possibly also that of the operator, is part of the well-defined DICOM tags. Viewers can usually make these DICOM headers or metadata visible and even allow them to be edited.

Another source where personal data can be part of the DICOM data are the so-called “burned-in annotations”. The following example shows that the patient’s name and date of birth: As you can see the personal information Max Mustermann, born on 19 August 1938 – don’t worry, this is a fake person – is part of the pixel information and can only be removed with special tools, usually by drawing black boxes over the visible information.

Figure 1: Burned-in annotations in echocardiography

Also, DICOM studies often contain series which hold patient reports or dicomized letters with patient private information. These reports are normally in series marked with modalities like PR, SR or OT.

Depending on the needs of a clinical project, the user must be cautious and decide which information shall be shared or not. Finally, we want to mention, that the reconstruction or 3D rendering of images by an increasing special resolution, can lead to a patient identification. If for example CT or MRI slices of a head from a patient are rendered, the facial features can be reconstructed and allowing the identification of patients.

It’s our article’s objective to increase the awareness of healthcare professionals dealing with medical images and as such with personal patient information or often called Private Health Information (PHI). However, you might be glad to hear, that exchanging does not need to be complicated at all, for example with the use our dicomdrop- and decidemedical-tools.

You would like to learn about different ways to exchange DICOM files? Then stay with us: In part 3 of our DICOM explained-series, we will explain the different options available for DICOM-exchange and will tell you more about their pros and cons.

For more information on our ClinFlows-solutions, visit our website or get in touch via info(at)clinflows.com!

Categories
DICOM GDPR

DICOM explained Part 1: What is DICOM, DICOM Tags and Data Sets?

Imaging techniques play an important role in many areas of modern medicine. This applies to diagnostics and therapy, but also to research, for example, in the context of clinical trials. The most important medical image format is DICOM. 

Within clinical projects, utilizing our ClinFlows’ solutions to exchange medical images, we frequently meet users (physicians, study nurses and coordinators) who are not that familiar with the topic “DICOM”. Time for us as DICOM experts to start a series in which we explain the format and obstacles that come when dealing with it (spoiler: among others, it’s about personal data!).

In the coming time, we will gradually publish articles here in which we explain the most important background and facts about DICOM data. We start today with part 1 of our DICOM explained-series, in which you will learn what is behind the abbreviation, how the DICOM format is structured, what makes it so characteristic and what it is used for in healthcare.

DICOM: the format behind the five letters

JPEG, TIFF, PNG – almost everyone knows these file formats of images. DICOM is also an image format, but it is used primarily in the medical industry. The abbreviation DICOM stands for “Digital Imaging and Communications in Medicine”. The term already makes it clear that the format not only includes the respective image data, the pixels or its storage as a specific file format, but that the DICOM standard includes further information, which we will explain in more detail later. The DICOM standard has its origins in the 1970s, when it was still called the ACR/NEMA standard and was initiated by the American College of Radiology and the National Electrical Manufacturers Association. DICOM as we know it today has only existed since 1992. The use of this image format is intended to facilitate and standardize the exchange of medical image data.

DICOM: Open standard to exchange medical images

The DICOM format is one of the so-called open standards, openly accessible and usable by anyone. This allows many medical professionals in the fields of research and clinical practice, diagnostics and therapy to exchange, view and perform measurements of medical images independently of manufacturers.

What are DICOM Headers, DICOM Tags and Data Sets?

A set of medical images in DICOM format usually has the following overall structure: Patient – Exam – Series – Images. That is, a patient undergoes a study or examination, such as a computed tomography (CT) scan. This examination consists of several series, and each series contains multiple images (hundreds or thousands) or multiple frames (like a video, e.g., for echocardiographies).

A DICOM medical image file, such as a single CT slice, consists of two distinct parts. One is the medical image itself, the other is the DICOM header. The DICOM header is a block of data that contains specific information that complements the image, called DICOM tags. This usually includes relevant patient data such as name, age, gender and date of birth, but also a lot of technical data and parameters, such as the device used to generate the images, the names of the surgeon and the administered drugs such as contrast agents, as well as data on the imaging technique, such as pixels, matrix size or the dimensions of the image. This usually facilitates the assignment of an image to a patient. In medical jargon, this data is referred to as attributes. Depending on the image and the circumstances, certain information is mandatory, while other attributes are optional. In addition, the DICOM header has DIN standards, which are defined by law.

What are DICOM Tags good for?

The DICOM Tags are organized as a constant and standardized series; thus, they are used in the management of information belonging to medical image data. The DICOM Tags are assigned as metadata elements to each image object in medicine. These can be segmentations, definitions of surfaces, and registration numbers for the images. The format is used for both standardization and storage of the files, as well as a uniform communication protocol for sharing. As data elements, tags consist of an attribute that is used for identification. Usually they are composed of hexadecimal numbers (XXXX,XXXX) with a comma in the middle. If necessary, a further subdivision into the group and element number is possible. In this way, DICOM tags are easier to read, and patient data can be printed directly on them when developing X-ray images. In this way, the X-ray image and the associated data are combined digitally in one file.

What DICOM Tags are available?

There are a variety of DICOM tags that assist in organizing medical image data as well as searching for them. These include, for example:

DescriptionNumber
Accession Number0008,0050
Procedure Creation Date0014,4076
Modality0008,0060
Patient’s Birth Name0010,1005
Operator’s Name0007,1070
Patient’s ID0010,0020
Patient’s Birth Date0010,0030
Patient’s Body Mass Index0010,1022
Table 1, DICOM Tags

Thanks to the numbers, an extremely large amount of information can be assigned to the images, which is immediately recognized by the medical authorities. By the way: A full list of all DICOM tags can be found at MITA (The Medical Imaging Technology Association) or NEMA here.

In the next part of our DICOM explained series, we will dive deeper into the topic: Among others, you will learn more about the problems that the data contained in DICOM files pose for working with them. Stay tuned!

Categories
Case Study clinical decision support decidemedical GDPR

Case study: How to provide clinical decision support during post-training phase

They are essential to our health: new medical products. Every year, medical device manufacturers, biotech companies, and pharmaceutical companies spend billions to develop them – and then millions to train and educate physicians to know how to use them and how to best help patients. But what happens after that, and how can medical product manufacturers support physicians when it comes to treating real people?

Once a medical product or treatment has been developed, various methods are initially used in the training phase. These range from descriptions and instructions supported by e-learning platforms, videos and audio files to sophisticated training centers with hands-on learning in real operating room facilities with training on animals or cadaver explants. Simulation software and 3D-printed artificial materials to mimic real-world scenarios are also emerging technologies for training and preparing physicians to use new treatments.

Time gap between training and first patient treatment

All of these efforts are designed to prepare medical teams for the moment when a real patient is to be treated. Right after training, what usually happens first is…. nothing! That’s because often the first treatment of a real patient doesn’t happen until weeks or months after training. This is the moment when training and reality meet. 

Now it’s up to the physician in his or her clinic to decide whether the patient meets the criteria for a particular implant or interventional treatment. The physician may need to select the right size implant or decide on the access route. 

Assessment of medical images vital during post-training-phase

Medical images play a key role in the best treatment outcome, such as methodological selection and determining the size of an implant. And this is where medical device manufacturers can come in: Namely, by supporting physicians with a second opinion at these critical moments. But this is not always so easy and, above all, often too slow, for example because of a physical distance. It is not uncommon, for example, for the attending physician and his patient to be located in Europe, but the manufacturer in the USA, and for medical images to be exchanged by mail.

Clinical decision support via web-based tools to ensure the best treatment possible

A straightforward and secure solution here can be provided by web-based clinical decision support tools, such as our GDPR-compliant online solution decidemedical, which has been used by the medical device industry for ten years. With its help, clinicians can upload their clinical data and medical images and submit them securely and compliantly to industry experts to either get their opinion on the suitability of a case or industry provides sizing services. Clinical experts from the manufacturer review and measure the medical images using specialized imaging software and submit their assessments to the physician via the web-based platform to recommend the best treatment option and implant size.

The benefits to the physician, the industry – and most importantly, the patient – from using web-based Clinical Decision Support tools in the post training phase are clear:

  • Utilization of existing medical expertise,
  • available worldwide,
  • fast turnaround time,
  • enables a controlled product launch,
  • efficient customer support,
  • compliance with regulations, and it’s
  • accessible from anywhere – no software required.

How do you manage physician support in the post-training phase? And how does your clinical team share medical images with the different sites?

Discuss here or contact us at info(at)clinflows.com

Categories
GDPR

ECJ invalidates Privacy Shield – what does this mean for you and your company?

The European Court of Justice (ECJ) declared the Privacy Shield invalid in its ruling (C-311/18) on 16 July 2020. We have summarized here what this can mean for you and your company.

Data protection, the exchange of data and what has to be considered – I know that this is not a very funny or entertaining topic. Nevertheless, it is one of great importance, especially in the healthcare market. Why? 

Because in our healthcare market, doctors and industry personnel deal with patients’ personal data on a daily basis and transmit it online, whether for clinical studies, sending medical images (DICOM) to CoreLabs or to obtain a second opinion from medical experts for screening purposes or to check the suitability of a patient for a particular treatment – sometimes across several continents. And here comes the problem:

Following the rejection of the Safe Harbor Agreement in October 2015, the replacement Privacy Shield, which was a self-certifying mechanism for U.S. companies to comply with privacy requirements when transferring personal data from the EU to the United States, was declared invalid in July 2020.

European personal data not protected in the USA: U.S. government may use communications providers to monitor foreign individuals

The reason: the ECJ found that the US surveillance programmes allow the US authorities to carry out large-scale surveillance activities that do not comply with the principles of European standards, in particular with regards to necessity and proportionality. An example of this is the hotly debated Section 702 of the FISA (Foreign Intelligence Surveillance Act), a key provision of the FISA Amendments Act of 2008, which allows the U.S. government, with the help of electronic communications service providers to conduct targeted surveillance of foreign persons located outside the United States in order to obtain foreign information.

Furthermore, the mechanism of the so-called “ombudsperson” embedded in the Privacy Shield does not actually offer a realistic possibility for the persons concerned to bring their legal dispute before an independent court, as provided for in the Charter of Fundamental Rights of the European Union.

The problematic situation was clearly expressed by Mr. Schrems, the founder of the NOYB-European Center for Digital Rights, who stated during a hearing before the EU Commission on September 3: “(…)we have a fundamental clash of laws. We have in the European Union, the Charter of Human Fundamental Rights and in the US, FISA (…) there is a legal clash (…) having two different obligations on the legislative level, in the US to have surveillance and in the EU the obligation to privacy (…)“.

Why could this be a problem for European companies?

Well, the answer is simple: If you and your company rely on service providers for the exchange of European patient data, then you need to check: 

1. where are the data hosted – US or EU?

2. where is the company located processing your data?

If you host your patient data on US servers, or utilize services from a data processor which has its headquarters located in the USA your data is at risk to be surveilled.

The question now is what the European data protection authorities will do about it. It must be remembered that the European Court of Justice’s ruling obliges the authorities to act as the ruling is binding. Their measures are under discussion and must be awaited.

So we are not only dealing with a complex legal situation that makes it difficult for the industry to operate and make clear decisions, but also with questions such as: Are the standard contractual clauses sufficient or should supplementary measures be taken? At present, we also do not know what the consequences of the measures to be taken by the data protection authorities will be.

Will data from your EU patients be transferred to the USA?

I am often surprised when I speak to senior clinical or business managers in the healthcare industry who have to manage the transfer of personal data of patients, such as medical images as part of clinical monitoring or study projects. Often, they have little knowledge of the current discussions regarding data transfer between the EU and the US – often they don’t even know in which country their project data is hosted. Also, the term “anonymized” data is often used incorrectly, because in fact, data is usually only pseudonymized, which has completely different legal consequences than anonymization.

I can clearly recommend any manager who manages the transfer of personal patient data: Make every effort to understand where the relevant data is hosted and whether it is hosted by a U.S. or EU entity that handles the data, so that you can assess how much of a risk the U.S. authorities are monitoring. 

The solution: Hosting European patient data on European servers using European providers

It is clear that it will be almost impossible to prevent the US authorities from monitoring EU-US data transfers and that it will take years, if ever possible, to resolve these issues legally.

Therefore, for the security of the privacy of our patients in Europe in the context described above, it is strongly recommended to ensure that the data is hosted in Europe by a European company as data processor – only then will the US authorities not have access to the data.

And guess what, yes, that is exactly what we offer at ClinFlows: ClinFlows only uses dedicated servers located in Europe to process data – because the security of the patient data we process is our top priority.

And we promise you: We will continue to monitor the recommendations of data protection authorities to ensure that appropriate mechanisms are implemented and that our services remain secure for all parties involved.

About the author:

Uwe Gladbach is a biomedical engineer, who started his career as a perfusionist in open heart surgery back in the 90ties. In more than 25 years he gained experience in the medical device industry in various positions, covering clinical research, as well as sales and operations in global positions. Uwe is the CEO and founder of ClinFlows, which offers e-solutions for clinical workflows.