| Literature DB >> 30326890 |
Pantelis Natsiavas1, Janne Rasmussen2, Maja Voss-Knude3, Κostas Votis4, Luigi Coppolino5, Paolo Campegiani6, Isaac Cano7, David Marí8, Giuliana Faiella9, Fabrizio Clemente9, Marco Nalin10, Evangelos Grivas11, Oana Stan12, Erol Gelenbe13, Jos Dumortier14, Jan Petersen2, Dimitrios Tzovaras4, Luigi Romano5, Ioannis Komnios15, Vassilis Koutkias16.
Abstract
BACKGROUND: Increased digitalization of healthcare comes along with the cost of cybercrime proliferation. This results to patients' and healthcare providers' skepticism to adopt Health Information Technologies (HIT). In Europe, this shortcoming hampers efficient cross-border health data exchange, which requires a holistic, secure and interoperable framework. This study aimed to provide the foundations for designing a secure and interoperable toolkit for cross-border health data exchange within the European Union (EU), conducted in the scope of the KONFIDO project. Particularly, we present our user requirements engineering methodology and the obtained results, driving the technical design of the KONFIDO toolkit.Entities:
Keywords: Barriers and facilitators for HIT acceptance; Cross-border health data exchange; Cybersecurity; Digital health; Gap analysis; Health information technologies (HIT); Interoperability; User requirements engineering
Mesh:
Year: 2018 PMID: 30326890 PMCID: PMC6192123 DOI: 10.1186/s12911-018-0664-0
Source DB: PubMed Journal: BMC Med Inform Decis Mak ISSN: 1472-6947 Impact factor: 2.796
Fig. 1The user requirements engineering framework: methodological pillars and main outcomes
The second reference scenario considered in KONFIDO
| Phase 1: Milan |
Terms highlighted in bold indicate verbs or phrases that have been used to identify the respective BPs in the scenario
Fig. 2Partial view of the workflow corresponding to the user scenario described in Table 1
Business processes identified from the user scenarios
| ID | Business process | Description |
|---|---|---|
| BP1 | Grant access to own Medical Record | A patient in the visiting country grants the foreign HCP access to his/her medical record to facilitate treatment. |
| BP2 | Access the medical record of a foreign patient | The HCP accesses a foreign patient’s medical record, e.g. his/her medical history summary, medication treatment plan, diagnosis and relevant lab examination results. |
| BP3 | User authentication using the national eID infrastructure | The user is being authenticated via his/her nationally-issued eID. |
| BP4 | Transmitting data for remote monitoring | The user transmits data using a telemonitoring service. |
| BP5 | Accessing the patient’s medical record while transferred via an ambulance | Paramedics retrieve data from the patient’s medical record. |
| BP6 | Exchanging triage information, while the patient is transferred to the hospital via an ambulance | Paramedics transmit triage data to the respective hospital, e.g. wound pictures. The application transmits patient data in the ambulance and may provide guidance to the paramedics. |
| BP7 | Exchange of medical information between HCPs | HCPs exchange medical information directly, e.g. in the case of a medication safety issue, and notify the treating physician accordingly. This BP refers to an active way of communication and not to keeping notes in the patient’s medical record. |
Assets identified for BP2: “Access the medical record of a foreign patient”
| ID | Description | Category | Comments |
|---|---|---|---|
| A1 | Medical record information | Information | The main asset to be protected. |
| A2 | HCP credentials | Information | e.g. usernames, passwords etc. |
| A3 | HCP authentication means | Infrastructure | e.g. eID card |
| A4 | Intention of accessing medical record | Information | The intention of accessing a patient’s medical record is crucial. On the one hand, it could imply an attack attempt and, in this case, the medical record owner should be notified. On the other hand, it should be protected as it clearly implies that the doctor intends to conduct a medical transaction, and this could contain sensitive information. |
Threats identified for BP2: “Access the medical record of a foreign patient”
| ID | Type | Assets | Malicious actors | Description/Example scenario |
|---|---|---|---|---|
| T1 | Spoofing | All information assets | Other actors without a clear role in the BP | An external actor could pretend to be legitimate, in order to get the HCP credentials and use them to access information (e.g. patient’s medical record), on behalf of the HCP. |
| T2 | Tampering | All information assets | Other actors without a clear role in the BP | A malicious user could (perhaps combined with a spoofing attack) modify the information assets (e.g. the patient’s medical record or the HCP’s credentials) in a malicious way for social, financial or for personal reasons. |
| T3 | Repudiation | All information assets | HCPs | Deny accessing medical information to avoid legal consequences upon an HCP (e.g. in a case of a medical error). |
| T4 | Information disclosure | All information assets | HCPs and other actors without a clear role in the BP | An HCP could provide access to a patient’s medical record, aiming at patient’s financial or personal harm or for personal financial benefit. |
| T5 | Denial of Service | Medical record information | Other actors without a clear role in the BP | Hinders access to the respective services, aiming to cause damage to the patient or the healthcare organization providing the medical services. |
| T6 | Privilege Elevation | Medical record information | Other actors without a clear role in the BP | Assign privileges to one or multiple medical records aiming at exploiting or damaging data, or alternatively aiming at patients’ financial or personal harm. |
| T7 | Physical stealing | Physical authentication means | Other actors without a clear role in the BP | Stealing the eID card of the HCP could facilitate spoofing, information disclosure and privilege elevation. |
Goal 11: “Prevent tampering attacks”
| G11 | Prevent tampering attacks |
|---|---|
| Goal Type | Non-functional |
| Actor(s) | Other actors without a clear role in the BP |
| Reference(s) | BP2 |
| Description | As someone could (perhaps combined with a spoofing attack) modify the information assets (e.g. the patient’s medical record or the HCP’s credentials) in a malicious way for social, financial or personal reasons, KONFIDO should be able to prevent such kind of malicious actions. |
Goal 12: “Prevent ambiguity issues”
| G12 | Prevent ambiguity issues |
|---|---|
| Goal Type | Functional |
| Actor(s) | HCP, Patient |
| Reference(s) | BP1, BP2, JASeHN deliverable D5.3 (section IV) |
| Description | Semantic ambiguity can be a burden in cross-border health data exchange. Referencing to diseases and medication might be confusing in clinical practice due to different drug brand names, clinical protocols/procedures, etc. KONFIDO should promote semantic interoperability in order to minimize these risks. |
Fig. 3Sankey diagram illustrating an indicative view of links among specific information sources considered in the analysis
Fig. 4Sankey diagram illustrating the overall contribution of the categories of information sources considered in the analysis for goal definition
Origin of user goals with respect to the information asset categories considered in our meta-analysis
| Original source category | Percentage of goals referring to the category |
|---|---|
| Standards | 29% |
| Business Processes | 24% |
| Threats | 13% |
Indicative gaps identified in the PAUSIL hospital
| Gap analysis template clause | Gap analysis objective | Question/security control | Current status and gap mitigation |
|---|---|---|---|
| Security Policy | Information security policy | Does the analysis subject facilitate or promote the idea of information security policy document? | A formal information security policy document does not yet exist; however, PAUSIL is planning to introduce operational procedures and policies regarding security. |
| Physical and environmental security | Secure areas | Does the analysis subject facilitate or promote protecting against external and environmental threats? | Protection against external and environmental threats is not centrally documented/planned. |
| Usability | Effectiveness | Does the analysis subject facilitate or promote the operability regarding the respective security aspects? | The process of changing user passwords could be improved in terms of usability. |
| Communications and operations management | Media handling | Does the analysis subject facilitate or promote management of removable media? | No formal procedures are enforced for the management of removable media |
Fig. 5Answers to question “Have you ever thought about your privacy regarding your health data?”
Fig. 6Answers to question “Do you feel well-informed regarding possible health data security risks?”
Fig. 7Answers to question “Please rank the importance of the issues that you think might facilitate the adoption of security-oriented best practices” (for readability, only the most popular responses are presented)
Fig. 8Answers to question “Please rank the following barriers, hindering acceptance of cross-border health data exchange”
Barriers for HIT acceptance linked with cybersecurity and interoperability
| ID | Description | Expected impact on technical design and/or the overall KONFIDO project activities | Category |
|---|---|---|---|
| B1 | Lack of awareness regarding information technology risks | Need to reinforce awareness on cybersecurity risks associated with healthcare delivery. | Awareness |
| B2 | Lack of end-user confidence on their overall electronic health data handling | The technical design shall account for a comprehensive and transparent data handling scheme. | Trust |
| B3 | Lack of trust to private companies providing HIT services | The solution should focus on using infrastructure in the most transparent way possible. | Trust |
| B4 | Lack of interest regarding the “Terms and Conditions” for using HIT services | ▪ Need to make “Terms and Conditions” more comprehensive for all users. | Trust |
| B5 | Inadequate level of legislation awareness | Need to promote awareness on legislation aspects. | Awareness |
| B6 | Lack of perceived effectiveness of legislation by end-users | Need to explain and illustrate the effectiveness of legislation to end-users. | Trust |
| B7 | Lack of clear and transparent consent processes currently applied | Need to design a comprehensive consent mechanism. | Trust |
| B8 | Legislation not aligned among EU Member States | Need to track ongoing legislation initiatives and adapt the technical design accordingly. | Legislation |
| B9 | Immaturity of existing frameworks | Need to reduce strong dependencies with such frameworks to the extent possible. | Usability |
| B10 | Partial lack of management commitment | Need to raise awareness on cybersecurity risks associated with healthcare delivery. | Awareness |
| B11 | Lack of a cybersecurity-oriented culture in everyday operations | Need to raise awareness on the cybersecurity risks associated with healthcare delivery. | Awareness |
| B12 | Lack of budget | Need to raise awareness on the impact of cybersecurity incidents and the economic burden that these may entail. | Awareness |
| B13 | Usability reduced due to IT security measures | Need to prioritize usability in the technical design process. | Usability |
| B14 | Inadequate use of established cybersecurity mechanisms (e.g. active directory, intrusion detection systems, etc.) | Need to promote the use and added value of novel/standard cybersecurity mechanisms. | Awareness |
| B15 | Diversity of information workflows among organizations | Need to contextualize the technical design, in order to accommodate the requirements of local healthcare delivery processes and therefore increase end-user acceptance through enhanced usability. | Usability |
| B16 | Free-text content in different languages | Need to employ reference medical terminologies/encodings to address interoperability. | Interoperability |
| B17 | Legislation not aligned among EU Member States | Need to follow ongoing legislation initiatives and adapt the design according to EU directives. | Legislation |
| B18 | Legal issues not clarified (e.g. data ownership, liability etc.) | Focus on provenance and auditing mechanisms, in order to clarify details if/when needed and, therefore, increase trust on the overall data exchange process. | Legislation |
| B19 | Lack of inter-organizational trust | Need to promote robust and transparent cybersecurity measures while illustrating the added value of health data sharing (e.g. considering patient safety, quality of care, etc.). | Trust |
| B20 | Complexity of consent process | Need to design a comprehensive consent mechanism for patients. | Usability |
| B21 | Lack of available IT expertise in organizations | Need to raise awareness about the required personnel to address cybersecurity risks in organizations delivering healthcare services. | Awareness |
| B22 | Data exchange agreement’s complexity | Need to establish data exchange agreements compliant with legal norms. | Usability |
Facilitators for HIT acceptance linked with cybersecurity and interoperability
| ID | Description | Expected impact on technical design and/or the overall KONFIDO project activities |
|---|---|---|
| F1 | The need for HIT services and applications tends to overcome the insecurity regarding personal data misuse | It confirms the need for solutions that provide added value in real-world healthcare settings, while still promoting a holistic security approach. |
| F2 | End-users support cross-border data exchange (even for research) | It confirms the value of the KONFIDO key concepts. Does not affect design decisions. |
| F3 | Common legislation activities between EU Member States | GDPR and other initiatives will form the legal base for the solution and guide the respective design decisions (e.g. on the consent process). |
| F4 | Technical EU initiatives are currently ongoing | The design will create a liaison with and build upon existing/evolving frameworks in Europe (epSOS, OpenNCP, eIDAS). |
| F5 | Standards already established and widely accepted | The design and implementation will follow security standards, such as those from ISO/IEC 27k. |
| F6 | Wide recognition of the need for a security policy based on standards | The technical solution should be based on widely-accepted standards and therefore implicitly increasing compatibility with standard based security policies. |
| F7 | Exchange of data between organizations is based on agreements following GDPR | The design shall take GDPR into account wherever applicable (e.g. in the design of the consent process). |
| F8 | Common mechanism of eID currently built (eIDAS) | The design of the solution shall be based on eIDAS, which is expected to be the de-facto standard among EU Member States. |
| F9 | Cloud services, compatible with medical data exchange legislation | KONFIDO will be able to use cloud infrastructure being compatible with the respective legislation. |
| F10 | Credible network services available | Facilitate the engagement in high mobility scenarios. |