For several years now, Germany has been preparing to introduce an electronic health card (elektronische Gesundheitskarte, eGK) a smart card with an embedded microprocessor which allows additional functions, in particular verifying one’s digital identity within the telematics infrastructure of the health-care sector. The smart card will initially contain the cardholder’s administrative data which are already on the magnetic health insurance card. The possibility to store additional data (such as prescription drug records, emergency medical information, electronic patient records) is to be added later.
With the new electronic health card, data protection for patients should at least be no worse than under the current system. The intention is even to improve transparency for insured persons and give them extensive options for using their medical data. Cardholders are to have control over the data in all the applications they choose, and to be able to decide themselves as far as possible how much of their health-related data should be stored on the smart card and in the telematics infrastructure and how it should be used. The smart card is to be designed with technical features giving cardholders the ability to manage their own data and the rights to access that data.
The card and the telematics infrastructure must be simple enough for cardholders to use. Processes suitable for everyday use which enable ordinary users to actively exercise their data sovereignty and rights as patients are a basic prerequisite for introducing the electronic health card and operating the telematics infrastructure.
Efforts to modernize the health-care sector must pay attention to strengthening patient sovereignty and patients’ rights and to expanding patients’ participation. If the use of IT in the health-care sector were to focus only on improving cost-effectiveness and speeding up processing times while neglecting data protection and patients’ rights, it would find little acceptance and would have little chance of being implemented.
This is why the technical processes must be suitable for everyday use by all insured persons, so they can actively exercise their rights of participation and control. In this way, the electronic health card and telematics infrastructure offer the chance to improve access to health data, optimize medical treatment and at the same time enhance patients’ control over their own data. The technology used must guarantee lasting compliance with the principles of data protection.
Lastly, the entire technical infrastructure must be oriented above all on benefiting patients. All components, interfaces, services and processes in the health telematics must function optimally and meet the requirements of data protection and data security.
Everyone involved in developing the electronic health card has agreed to abide by the following principles:
Data sovereignty: The insured person has extensive control over his/her health data to be processed in the electronic health card or the telematics infrastructure. The voluntary medical applications can be used only with the express consent of the insured person and specific access granted by him/her.
Voluntary basis: Health data are to be stored only on a voluntary basis, at the discretion of the insured person. No preferential or discriminatory treatment is allowed on the basis of data access granted or denied by the insured person.
Extent of data: The insured person must be able to decide which health data are included and when they should be deleted.
Data access: The insured person must be able to decide on a case-by-case basis which service provider (physician, pharmacist, midwife, etc.) has access to which data.
Right to information: The insured person has the right to read his/her own data and the right to information about them and all processes concerning them.
Ability to check: The insured person must be able to use logs to check who accessed which data and when.
The technical processes currently being tested and the robust security mechanisms built into the smart card and the telematics infrastructure are intended to ensure compliance with these data protection principles and thus also the active participation of insured persons in granting access and managing their medical information and access rights.
Data protection and data security have been taken into account when designing the processes and technology. All the components which are essential to data security—that includes all components involved in encrypting data and ensuring the authenticity of participants—must be certified in accordance with a protection profile of the Common Criteria in order to verify their trustworthiness.
All users—patients, insured persons and members of the health professions—must be able to use the systems securely and easily. Processes for data subjects to actively exercise their rights are to be practical and suitable for everyday use, so that the new technology does not discriminate against anyone (such as elderly or ill persons); among others,
insured persons cannot be assumed to have technical devices,
insured persons must be able to use these processes conveniently in the context of treatment, for example at the doctor’s office or when filling an electronic prescription at a pharmacy, and
it must be possible to manage applications and rights using a convenient, standardized and easily understandable interface.
The practicality of a system and its suitability for everyday use is an important criterion for the ability to manage the system and provide effective data protection. All business processes must be understandable and as simple as possible for all involved. This criterion places high demands on the design of applications for insured persons, because all insured persons, not only those with advanced computer skills, must be able to exercise their rights. The generally applicable rule of not discriminating against persons with few computer skills applies especially to the health-care field. Particularly when designing systems, it is important to make sure that the new technology does not discriminate against elderly or ill persons.
However, the more complex a system and its security functions become (e.g. the length of passwords or PINs, different rights for different user groups), the higher the demands on system participants. After a certain point, such complexity becomes counterproductive: As applied in practice, processes are less effective and less transparent and may create undesirable side effects and new security risks.
That is why it is necessary to clarify in advance how to deal with certain foreseeable constellations in which insured persons are unable to operate the security functions of the electronic health card. This applies to persons with a physical or mental disability, for example, and for persons in extreme situations, such as when the insured person is unconscious and immediate access to certain medical data is essential. One solution might be for cardholders to give their physician the power to manage access rights when they are unable to do so themselves. But even in this case, it is necessary to guarantee that the data subject ultimately decides who has access to his/her data and when.
This is why the design of the system must be carefully planned. Key components of the system are currently undergoing a large-scale test in which system specifications will need fine-tuning, depending on the practical experience gained.
In my view, the electronic health card could become a model for ensuring data protection and data security using privacy-friendly technology, if the design principles listed are consistently implemented. Both the health-care sector and the rights of data subjects could benefit from the new smart card.
However, since the initial rollout of the electronic health card, there have recently been indications that not all participants are willing to bear the costs of the complex infrastructure required by data protection law. For example, certain circles of the medical profession have objected to having to buy new hardware to meet security standards and have called for using software solutions instead, in order to cut costs. I doubt whether the intended and legally mandated security standards can be achieved in this way.