1 / 46

Dagstuhl Seminar Model-Based Design of Trustworthy Health Information Systems:

Dagstuhl Seminar Model-Based Design of Trustworthy Health Information Systems: Data Protection Requirements for setting up EHR Systems and the “Austria ELGA Policy”. Klaus Schindelwig February, 12th, 2009. Content. Motivation EU Directive 95/46/EC and WP 131 Existing Models

duncan
Télécharger la présentation

Dagstuhl Seminar Model-Based Design of Trustworthy Health Information Systems:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dagstuhl Seminar Model-Based Design of Trustworthy Health Information Systems: Data Protection Requirements for setting up EHR Systems and the “Austria ELGA Policy” Klaus Schindelwig February, 12th, 2009

  2. Content • Motivation • EU Directive 95/46/EC and WP 131 • Existing Models • Development e-health • a Policy for ELGA (EHR) in Austria

  3. Motivation Motivation • growth of health care budget deficits • increased expectation of life • multi-morbid patients • Increasing medical specialization EHR systems have the potential to achieve greater quality and security in medical information than the traditional forms of medical documentation. However, from a data protection point of view the fact has to be stressed that EHR systems additionally have the potential not only to process more personal data (e.g. in new contexts, or through aggregation) but also to make a patient’s data more readily available to a wider circle of recipients than before. (ARTICLE 29 Data Protection Working Party, WP 131)

  4. Motivation Requirements Creating a communication structure, to make available • information relevant for treatment • automatized • quality proofed • just in time • privacy compliant • interoperability • maintaining confidentiality and safety to the authorized persons at the right time.

  5. Motivation The Challenge it´s simple the, • „eierlegende Kommunikations-Wollmilchsau“

  6. Motivation Some problems we have to solve

  7. Motivation Solutions, ranked by technical challenge • Electronic health records supported by private or public institutions • Hospitals as health data provider • Exchange of health data via secured and proprietary data transmission (e.g. EDIFACT) between co-operating healthcare providers • e-mail • fax message • letter

  8. Motivation Communication ranked according to current usage (transferred documents) in health care (estimation) • letter • fax message • e-mail • Exchange of health data via secured and proprietary data transmission (e.g. EDIFACT) between co-operating healthcare providers • Hospitals as health data provider • Electronic health records supported by private or public institutions

  9. Motivation Two basic models for access to patient data at trans-regional • A uniform system of a single manufacturer for all involved communication parties • Uniform communication and documentation structure;  central defaults, which are mandatory (English model) • No uniform system, but mandatory uniform standards and uniform interfaces • to be preferred for investment protection reasons (existing systems can be kept / adapted)

  10. Motivation Independently of the models the question arises: Is there a common understanding, how privacy in such models should be realized? • Simple answer is NO!!!! For example a question from a Systems Analyst, Healthcare System, USA: “I'd like to know if other hospitals/medical groups are allowing employees to access their own patient information in Cerner.”

  11. Motivation Answers: • Yes, we do. ------------------------------------------------------------------------------------ • No, we don't. ------------------------------------------------------------------------------------ No, not without a signed authorization on file in Medical Records. All HIPAA and Release of Information rules apply to staff. In fact, it can be grounds for termination. Access is monitored by our Compliance officer. ------------------------------------------------------------------------------------ • The same applies for us and it isn't meant to be an ongoing viewing of ones own information, it is from an ROI perspective. Our HIM Director is also the HIPAA Privacy Officer and does frequent audits of what EMR's are being accessed. ------------------------------------------------------------------------------------ • We allow the employee to access their own chart just not any family members unless they have a ROI on file with Medical Records. Access is monitored and accessing other's charts is grounds for termination.

  12. Motivation Answers: • Our employees may access their own records once they sign a release form which is good for the length of their employment. If accessing charts for other family members or friends a release must be signed by the person whose chart they will access and it is good for 1 year. ------------------------------------------------------------------------------------ • We do allow employees to access their own medical record, and that of their children up to a certain age. For older children and other family members you must have a release signed in medical records. In auditing access, one of the things they look for is accessing medical records with the same name as yours. ------------------------------------------------------------------------------------ • We do not. Employees must fill out a 'request for information' with HIM like everyone else. In fact we have a report that indicates if you have accessed your record, a co-workers record, or any individual with the same last name. Unless you can justify the access, you can be terminated. ------------------------------------------------------------------------------------ • We allow employees to look at their own charts only, but we do not encourage it.  They may not look at any family members’ charts.  There have been those occasions when I’m trying to check something out in the system (‘where do I find’, etc.) that it has been handy to access my own record.

  13. Motivation Answers: • Absolutely not!  If an employee wants to access their own medical record, they need to fill out the proper consent for Medical Records, just like any other patient.  We audit, and people are disciplined to the point of being dismissed if they access even their own records without proper authorization ------------------------------------------------------------------------------------ • We allow all patients to access their EMR electronically using IQ Health. So if an employee has an IQ Health account their can look at their own records. The content of the records belong to the patient, the paper or electronic record belongs to the institution. So they can't ask to carry away the hard disk just as they can't have the paper record. Releases should be intended for sending information to another clinic or hospital, attorneys, insurance companies, etc.. If a patient is in our office and wants a copy of their chart, we would print it out for them without ROI. I want my patients checking their charts to make sure I am not missing something important. ------------------------------------------------------------------------------------ • No, not without a signed authorization on file in Medical Records. All HIPAA and Release of Information rules apply to staff. In fact, it can be grounds for termination. Access is monitored by our Compliance officer.

  14. Gegenstand und Motivation Directive 95/46/EC and WP 131 Background EU: • e-Health 2002 • e-Health 2005 • Part of e-Europe

  15. Gegenstand und Motivation Directive 95/46/EC and WP 131 Background EU: • e-Health 2002 • e-Health 2005 • Part of e-Europe

  16. Gegenstand und Motivation Directive 95/46/EC and WP 131 Gegenstand und Motivation Background EU eHealth action plan 2004: • In 2004, the Commission adopted the eHealth action plan - which covers everything from electronic prescriptions and health cards to new information systems that reduce waiting times and errors – to facilitate a more harmonious and complementary European approach to eHealth. • The plan sets out the steps needed for widespread adoption of eHealth technologies across the EU by 2010. • Faster rollout of high-speed internet access • Those groups in society which are least likely to have easy internet access, such as the elderly, disabled or unemployed are often those who have most need of health services. • The plan calls on Member States to develop tailored national and regional eHealth strategies to respond to their own specific needs. • Cultural differences, varying population profiles and geography all mean that regional and national health policies have to be developed individually. • Through sharing ideas and experiences across Europe, all our citizens can benefit more rapidly from efficient and reliable eHealth systems. • eHealth is an integral component of the EU’s i2010 policy framework which seeks to promote an open and competitive digital economy, ICT-related research, as well as applications to improve social inclusion, public services and quality of lifeNational/regional roadmaps (Mitgliedsstaaten, 2005) • .........

  17. Directive 95/46/EC and WP 131 EU Regulations • EC Data Protection Directive 95/46/EC • and in Directive 2002/58/EC on privacy and electronic communications, • and in the national laws of the Member States implementing these Directives • Any processing of personal data in EHR must also comply with the rules laid down in the Council of Europe Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data (ETS No. 108) and the Additional protocol to Convention 108 regarding supervisory authorities and transborder data flows (ETS No. 181).

  18. Directive 95/46/EC and WP 131 Working Documenton the processing of personal data relating to healthin electronic health records (EHR) • ARTICLE 29 Data Protection Working Party • 00323/07/EN WP 131 Adopted on 15 February 2007 • In this Working Document on the processing of personal data relating to health in electronic health records (EHR), the Article 29 Working Party provides guidance on the interpretation of the applicable data protection legal framework for EHR systems and explains some of the general principles. The Working Document also gives indications on the data protection requirements for setting up EHR systems, as well as the applicable safeguards.

  19. Directive 95/46/EC and WP 131 Working Documenton the processing of personal data relating to healthin electronic health records (EHR) 1. Respecting self determination 2. Identification and authentication of patients and health care professionals 3. Authorization for accessing EHR in order to read and write in EHR 4. Use of EHR for other purposes 5. Organisational structure of an EHR system 6. Categories of data stored in EHR and modes of their presentation 7. International transfer of medical records 8. Data security 9. Transparency 10. Liability issues 11. Control mechanisms for processing data in EHR

  20. Directive 95/46/EC and WP 131 • For the purposes of this Working Document, an “electronic health record (hereinafter: EHR)”shall be defined as • “A comprehensive medical record or similar documentation of the past and present physical and mental state of health of an individual in electronic form and providing for ready availability of these data for medical treatment and other closely related purposes.”

  21. Directive 95/46/EC and WP 131 special categories of data contained in Article 8 (1) of the Directive • “Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life.” • EHR systems in addition to the genaral rules subject to the special data protection rules on the processing of sensitive information contained in Article 8 of the Directive

  22. Directive 95/46/EC and WP 131 Article 8 (2) (a): “Explicit consent” • According to Article 8 (2) (a) of the Directive: • “Paragraph 1 shall not apply where: (a) the data subject has given his explicit consent to the processing of those data, except where the laws of the Member State provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject's giving his consent;” • Consent must be given freely • Consent must be specific • Consent must be informed

  23. Directive 95/46/EC and WP 131 Explicit • In contrast to the provisions of Article 7 of the Directive, consent in the case of sensitive personal data and therefore in an EHR must be explicit. • Opt-out solutions will not meet the requirement of being ‘explicit’. In accordance with the general definition that consent presupposes a declaration of intent, explicitness must relate, in particular, to the sensitivity of the data. The data subject must be aware that he is renouncing special protection. Written consent is, however, not required.

  24. Directive 95/46/EC and WP 131 Article 8 (2) (c): “vital interests of the data subject” • could be applied only to a small number of cases of treatment • and could not be used at all to justify processing personal medical data for purposes other than treatment of the data subject such as, • for example, to carry out general medical research that will not yield results until some time in the future

  25. Directive 95/46/EC and WP 131 Article 8 (3): “processing of (medical) data by health professionals” • three cumulative conditions: • the processing of sensitive personal data must be “required”, • and this processing takes place “for the purposes of preventive medicine, medical diagnosis, the provision of care or treatment or the management of health-care services” • and the personal data in question “are processed by a health professional subject under national law or rules established by national competent bodies to the obligation of professional secrecy or by another person also subject to an equivalent obligation of secrecy”

  26. Directive 95/46/EC and WP 131 Additional safeguards • However, even if all these prerequisites were fulfilled, the Article 29 Working Party must point out that EHR systems create a new risk scenario, which calls for new, additional safeguards as counterbalance: • EHR systems provide direct access to a compilation of the existing documentation about the medical treatment of a specific person, from different sources (e.g. hospitals, health care professionals) and throughout a lifetime. • A new risk scenario calls for additional and possibly new safeguards beyond those required by Article 8 (3) in order to provide for adequate protection of personal data in an EHR context.

  27. Directive 95/46/EC and WP 131 Article 8 (4): substantial public interest exemptions • In the context of EHR, the Article 29 Working Party notes that the arguments for introducing EHR systems (cf. I., above) may establish “substantial public interest”. • In some MemberStates a ‘right to health protection’ is enshrined in the constitution. This underlines the importance attributed to all appropriate means for bringing about “health protection”. • An EHR system in such legal environments would certainly be founded on “substantive public interest” as it is an instrument fundamentally intended to guarantee adequate medical assistance to patients. • Article 8(4) of the Directive could, therefore, serve as a legal basis for EHR systems, provided that all the conditions mentioned therein are fulfilled. In particular, suitable safeguards for the protection of personal data in an EHR system must be provided for.

  28. Existing Models in europe Examples of implementation status in the member states of the European Union • A lot of Info services and health portals • GIN • SOGIS • netdoktor • lifesensor • National efforts: • Small countries such as Denmark or Norway are leading( rather pragmatic solutions) • Implementation in the large nations slower (Introduction of the eGK in Germany  very complex)

  29. Existing Models in europe

  30. Existing Models in Europe Summary: Models in Europe • Different approaches to implement an EPA in Europe • focusing on medical content: standardized applications for documentation tasks(security not highest priority) • focusing on secure communication based on a smartcard solution:First introducing a secure infrastructure, medical content grows continuously with usage • Which is the right way?

  31. ELGA: Architecture and applications ELGA - Policy „A hyper-index with sophisticated search functions“ ELGA Doctor Portal HSP Index Citizen Card with PIN Authorization System Registry Master Patient Index reading writing Adaptor Adaptor Adaptor e-Report (radiology, laboratories) Discharge Summary … e-Medication Data Sources Adaptors: Interfaces which make existing applications compatible with ELGA Quelle: ELGA Machbarkeitsstudie (IBM), ARGE-ELGA, 2006, 2007

  32. ELGA - Policy ELGA View on Data health care provider Index HSP Master Patient Index Central Storageof Data Registry Patient Authorization System HSP – Local Storage of Data Radiology reports Laboratory reports Medication Discharged Summary Quelle: ARGE ELGA, Schanner/Hurch, 2008

  33. ELGA: Goal and purpose ELGA - Policy • A goal is it to make possible on the one hand for the authorized ELGA users in efficient way access to defined patient-related sensitive data and to protect on the other hand these data against unauthorized access by technical and organizational measures. • The purpose of ELGA is to improve the diagnostics and therapy of the patient’s treatment in qualitative and communication technical manner. • Therefore a structure is made available, to provide defined patient-related sensitive information to entitled persons. The information shall also be provided in an appropriate way for further external usage (e.g. discharge letter, laboratory findings, radiology findings and in further consequence also vaccination history,…).

  34. ELGA - Policy Data protection requirements • Who may when, for which time span, from which location, in which role, in which context, to which extent, in which way access which documents? • The security rules have to be balanced between privacy needs and usability. • It is often demanded, but not feasible to define a set of rules which provides exact definitions under which treatment conditions which type of information is needed. • Practicable is however a clear categorization of document types

  35. ELGA - Policy Structure of the ELGA regarding data contents • Only those data (document types categories according to medical specialties) should be uploaded automatically, which are substantial for the treatment and are approved for ELGA by the legal entity of the hospital. • The evaluation of the relevance is done by the health care provider, which provides the document. • Discharge letter, laboratory findings, radiology findings and e-medication are classified as substantial. • Via ELGA only those data can be accessed, which has been released explicitly for ELGA by a health care provider

  36. ELGA - Policy Opt In – Opt out • By default no documents will be provided in ELGA without the patient’s consent (Opt-In is necessary) • Therefore no general consent is necessary whether the Patient is willing to participate in ELGA. Without individual consent the Patient’s ELGA will be empty. • As a prerequisite an information campaign should be placed before starting the ELGA project. • The citizen has at any time the option to “opt out” from ELGA. Documents will not be physically deleted but will be no more accessible.

  37. ELGA - Policy ELGA information retrieval • Medical Treatment Context • An access is permitted only if the treating person has a defined relationship relevant for the treatment of the patient. (e.g. attending physician) • Patient identification • The correct verification of the patient’s identity is a mandatory prerequisite for every access to ELGA

  38. ELGA - Policy ELGA information retrieval • Check of Physical Presence • Information can only be retrieved if the health care provider has proofed the physical presence of the patient via a defined test procedure (e.g. patient’s smartcard) • Patient Consent • For an access to the patient’s ELGA, the patient has to sign a consent. The health care provider is in charge of this consent. • The consent is valid 28 days starting from the time of issuing and can be extended automatically, if a hospital stay still persists. The patient can also give a consent which is longer valid than 28 days containing also restrictions for the access. • The patient can revoke this agreement at any time. The revocation should be easy for the citizen.

  39. ELGA - Policy ELGA information retrieval • Filter criteria for the inquiry • Following filter criteria have to be implemented: • Temporal restriction • Type of document • Medical specialty • health care provider • These filter criteria must be selectable by the requesting persons. • The filter settings have to be documented/stored • At this time we have not defined how exactly the patient consent should be handled or logged

  40. ELGA - Policy Internal authorization system • Access rights have to be defined according to the user’s roles and tasks. • Each health care provider has to take care that only authorized employees have access to the ELGA system and its content. The health care provider is liable for maintaining the internal security (organizational and technical means have to be defined by the health care provider) • Via ELGA retrieved documents (external findings) can become a part of the internal electronic patient record (EPR) of the health care provider. • Further internal access to those documents can (for technical reasons) no more be according to ELGA regulations and lies within responsibility of the health care provider

  41. ELGA - Policy Data Security for ELGA requests • Mandatory encryption of transmitted data • according to the Austrian health telematics and e-governement laws • Logging • It must be possible to derive for each access the accessing person’s identity as well as the treatment context. • Minimum data record: • Timestamp of the access • Identification of the patient • Personal name • Identification of the health care provider • Filter criteria of the inquiry including result list of the inquiry • Accessed documents but not the detailed content of the documents • Actions (read, write, authorization change)

  42. ELGA - Policy Data Security for ELGA Requests Retain time for log data • Log files have to be retained at least 11 years and maximum 31 years!! Sanctioning of misusage • Every access to ELGA without the patient’s consent will be subject to legal sanctions. Authorization Matrix • A default for the access to different information types by role is defined by an authorization matrix. • The matrix can be modified according to an individual patient consent.

  43. ELGA - Policy

  44. ELGA - Policy

  45. ELGA - Policy Summary ELGA policy • The citizens can decide whether information about them is imported in ELGA or not. • Definition of an default authorization matrix for the access to different information types by role. Can be modified based on individual patient consent. • Before accessing ELGA the patient’s consent has to be obtained. • Via ELGA only data can be accessed, which has been explicitly released for ELGA by a health care provider. • Information can only be retrieved if the health care provider has proofed the physical presence of the patient via a defined test procedure. • Every ELGA access is subject to detailed logging. Logs have to be retained for several years.

  46. health@net Thank you for the attention Mag. Klaus Schindelwig, MSc. klaus.schindelwig@tilak.at Tel. 0043512 504 24406

More Related