OpenEHR and General Data Protection Regulation: Evaluation of Principles and Requirements

Abstract

Background Concerns about privacy and personal data protection resulted in reforms of the existing legislation in the European Union (EU). The General Data Protection Regulation (GDPR) aims to reform the existing directive on the topic of personal data protection of EU citizens with a strong emphasis on more control of the citizens over their data and in the establishment of rules for the processing of personal data. OpenEHR is a standard that embodies many principles of interoperable and secure software for electronic health records (EHRs) and has been advocated as the best approach for the development of hospital information systems. Objective This study aimed to understand to what extent the openEHR standard can help in the compliance of EHR systems to the GDPR requirements. Methods A list of requirements for an EHR to support GDPR compliance and also a list of the openEHR design principles were made. The requirements were categorized and compared with the principles by experts on openEHR and GDPR. Results A total of 50 GDPR requirements and 8 openEHR design principles were identified. The openEHR principles conformed to 30% (15/50) of GDPR requirements. All the openEHR principles were aligned with GDPR requirements. Conclusions This study showed that the openEHR principles conform well to GDPR, underlining the common wisdom that truly realizing security and privacy requires it to be built in from the start. By using an openEHR-based EHR, the institutions are closer to becoming compliant with GDPR while safeguarding the medical data.

Integrating multiple blockchains to support distributed personal health records

“…These standards promote the interoperability of PHR data and are essential to ensuring interoperability and a unified view of these data. There are several popular standards for different parts of what can form complete PHR data, including DICOM (Digital Imaging and Communications in Medicine), 26 SNOMED-CT (SNOMED Clinical Terms), 27 and LOINC (Logical Observation Identifiers Names and Codes), 28 among others. Other protocols are broadly applied to standardize the format and high-level structure of PHR data.…”

“…Two widely recognized international standards used in various countries to structure interoperable PHR data are HL7 29 and openEHR. 21 These standards define a common structural format of PHR data, as well as enable the integration with specific formats, such as the DICOM, 26 SNOMED-CT, 27 and LOINC 28 standards.…”

Representation of Diagnosis and Nursing Interventions in OpenEHR Archetypes

“…The specifications of the openEHR standard are published by the openEHR Foundation, an entity responsible for developing the specifications and for the availability of specific tools that allow use of the standard, with one of the main objectives being to allow electronic health record (EHR) systems to communicate with each other without loss of meaning, achieving semantic interoperability. 1 To this end, the openEHR standard is based on two level modeling, 1 comprising the reference model and the knowledge model. 2,3 The reference model focuses on defining the structures and attributes necessary to express the instances of data in an EHR such as the data type and structure.…”

“…5 The openEHR foundation provides the Clinical Knowledge Manager (CKM) to enable reusing archetypes, which consists of a web-based repository containing archetypes and templates developed by an international group of experts. 1 These archetypes can be downloaded and reused directly or specialized to include specific elements and details for a given situation, such as the "weight" archetype, which can be specialized for "birthweight." 6 The application of the openEHR standard has been reported in several countries such as Sweden, 7 China, 8 Slovenia, 9 and Brazil.…”

“…5 The observations comprise recording measurable or observed data such as blood pressure or body temperature; evaluations are the record of clinical assessments such as the assessment of health risk or adverse reaction risk; instructions consist of recording the start of a work process such as a service request or medication order; and actions comprise performed clinical activities such as procedures and medication management. 17 The information in the input classes in openEHR can be structured in different ways such as (1) text that allows registering data in the form of a narrative; (2) date and time, which documents the date and time components in the EHR, may (for example) refer to the date and time of the evaluation or the beginning of the signs and symptoms; and (3) cluster, which is a format used to represent class logic and subclasses, in which broader content encompasses more specific content.…”