Interoperable System for COVID-19

In the year 2020, the world halted due to the spread of COVID-19 or SARS-CoV2 which was first identified in Wuhan, China. Since then, it has caused a plethora of problems around the globe such as the loss of millions of lives. India was one of the countries which were majorly affected by this pandemic. Thousands lost their lives and millions had to be hospitalized and taken into medical care. Due to this, there is an abundance of unorganized and redundant medical data in the Health Information Technology sector. Many hospitals contain various mismatched health records of a single person. We attempt to develop an Interoperable System specifically for COVID-19 using the openEHR standard to organize health records in digital form by creating Electronic Health Records. These records can be accessed and shared by multiple hospitals and clinics to reduce the redundancy of health records. This would establish effective communications between different hospitals and greatly make data sharing, efficient and low cost. Standardization can hugely affect medical errors. Interoperability provides hospitals to share across many channels and help Health care workers to detect discrepancies easily. Lives that are lost due to human error in the health care system can be minimized or even completely avoided. The number of hospitals using interoperable standards is still low and we hope that this paper will help make a change towards following the standard.


Introduction
The COVID-19 pandemic, also known as the coronavirus pandemic, is an ongoing global pandemic of coronavirus disease 2019 caused by severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2). Coronavirus is spread through droplets and virus particles released into the air when an infected person breathes, talks, laughs, sings, coughs or sneezes [1]. 2 The World Health Organization declared the outbreak a Public Health Emergency of International Concern on 30 January 2020, and a pandemic on 11 March 2020 [1]. Many countries halted public transports, large gatherings, and announced lockdowns to prevent the virus's further spread. The national lockdown for one day was announced on 24th March 2020 by the central government of India [2]. As a result of this lockdown, all regular out-patient departments across hospitals and clinics in India were to be shut, but emergency healthcare services would continue to function. Due possessed an unprecedented problem for the operating hospitals [3]. India hit two peaks of the highest number of Covid infections in a day on 12 September 2020 and 6 May 2021 with 97,894 and 412,431 cases reported respectively. During the last two years, the number of total infections reported is more than 32 million and increasing [4].
India is experiencing extraordinary furtherance in healthcare, wherein a colossal amount of patient data is being collected is very large. The amount of health data regarding COVID-19, that we are generating and being collected is going up at an exponential rate. Each patient may have multiple RT-PCR, Rapid Antigen or Antibody tests from different hospitals at different times. This data becomes redundant as there is no organization of these tests and their outcomes to which each hospital has access, to refer whilst treating a patient. Almost every hospital has a centralized system that contains patient data specific to the tests and treatments received at that particular hospital or clinic. Whenever the patient goes to a different hospital for a test or treatment a new EHR (Electronic Health Record) has to be created which would lack the previous record of the patient in other hospitals.
A need for an interoperable system for storing data regarding the attributes related to COVID-19 emerges to ensure the data quality and consistency which will enable meaningful and reliable use of longitudinal and heterogeneous data for public health, research and health service management. This would greatly reduce the redundancy and the discrepancy in the health records present with different hospitals and can be requested and retrieved simultaneously on the server by multiple hospitals. Such a system would establish a decentralized database for storing patient's information. This would enable hospitals to access previous records of a patient which in turn expedites a better treatment.

Background
Interoperability is the property of distributed systems to interact and exchange data or services with each other. Semantic Interoperability ensures that all parties involved understand the logic in these exchanges and the definitions of certain terms [6]. Standards spell out a definition for interoperability of a system [7].

OpenEHR Architecture
OpenEHR, which is maintained by the openEHR Foundation, is an open standard that ventures to convert health data from a physical paper form into an electronic form (EHR) and ensures universal interoperability among electronic data in all forms [9].
OpenEHR system is a dual model structure that divides the model into two levels: The archetype model in the OpenEHR architecture is made up of templates that consist of multiple archetypes.

Reference Model (RM)
The reference model in the OpenEHR architectures is building blocks that can be configured, constrained, and named by openEHR archetypes and templates forming document tree structures. 4

Archetypes and Templates
Archetypes are the basis for the OpenEHR standard, they can be considered Lego bricks. Archetypes are a set of names, rules and constraints describing how to use the RM building blocks to create a data structure. Some archetypes also contain translations in other languages so that they can be viewed in various languages [9]. Archetypes are used for making templates that can be used and reused for varied and specific use cases. They are used to address the complex information needs surrounding basic clinical ideas. Archetypes are gathered and maintained by openEHR Clinical Knowledge Manager (CKM) which is an international online clinical knowledge resource.
Templates are composed of two or more archetypes which are combined to make a larger structure for a specific use case, further constraints can be added to the templates when required. They can set default values, hide certain attributes and constrain values of archetypes. Templates do not add any novel concepts or attributes to the existing archetypes, they merely modify and restrict included archetypes.

Literature Review
In this section, we evaluate previous important and major research in the Interoperable systems and openEHR standards. Recently a large number of studies and research has been done on Health Care and interoperability all over the globe. Luís Filipe Reis et al. talk about an architecture that allows access to clinical data from different and diverse content sources for research purposes, in their paper [11]. Shelly S. et al. in their paper [12] point out that in developing countries like India, many healthcare organizations often adopt their own information systems without any regard for standards guidelines. This paper aims to build a standard health information system with support for multiple local Indian languages while sustaining Semantic Interoperability. Andre Araujo et al. [13] proposed a framework that supports Health Information Systems based on openEHR health care standards. They discuss problems faced by Health Information Systems like the consistency of Electronic Health Records (EHRs) and huge costs for maintenance of the system due to constantly improving and changing clinical concepts. It also talks about openEHR standards, archetypes and templates. This framework Interface establishes communication between the components and allows modifications in the GUI made using archetypes. Their results donate a reduction of 72% in development efforts to 5 code health applications. They used archetypes present in the Clinical Knowledge Manager (CMK) for validating the framework they proposed.

Environment Details
The system was made on a local computer with Intel(R) Core (TM) i7 7700HQ @ 2.80GHz processor with 16GB RAM and Node v14.17.6. The code was uploaded to Github for a collaborative effort on the system. Svelte was used for the User Interface.

Selection of Archetypes
The archetypes selected in this case were in accordance with COVID-19. To select archetypes OpenEHR Clinical Knowledge Manager [14] was used. The archetypes were then downloaded and stored in folders. In some cases the archetypes required may not be available, therefore new archetypes need to be created. This can be done by using Better's Archetype Designer [15]. All the archetypes needed for our system were found on the CKM [14].
The overview of types of archetypes to be selected are:

Building Templates
The archetypes were combined to form a template. To create templates from the archetypes selected and downloaded, OpenEHR Archetype Designer was used [15]. A repository was created to combine archetypes and the archetypes were uploaded. Archetypes were then uploaded to the repository as needed. A new template was then created and archetypes were added to the template. Some of the attributes in the archetypes selected which weren't needed were then hidden in the template. For Example, Age archetype consisted of chronological age, adjusted age and comment. The comment and adjusted age attributes were hidden in the template as they were not needed.
The template was then modified to set constraints on the values of certain attributes such as SpO2, which was limited to less than or equal to 100 and greater than or equal to 0 i.e. 0 <= SpO2 <= 100. When the modifications were completed the template was saved and exported in OPT (XML) and Web Template (JSON). The template in JSON format will then be used to create a user interface for the system. The template in XML format will be used to post to the Clinical Data Repository. •

User Interface
The task of making a user interface from the openEHR template is tedious at best, it was necessary to automate this task. Medblocks UI was used for this purpose. Medblocks UI is a Visual Studio Code extension that converts templates in JSON format to web components which can be used to create medical forms for users to fill. The data filled in the form can then be posted to the EHRbase as a composition. [16] A new Svelte project was created using Vite bundler and Medblocks UI was installed in VS Code. The template saved in JSON format was then placed in a folder named "Templates" where the svelte project was created. This step is necessary as Medblocks UI only detects templates placed in the "Templates" folder. The extension was then used to detect the template and the code formed was copied and pasted in a svelte component and then formatted. More styling was added to the form and using Shoelace.style and Tailwind CSS.

Setting up a Clinical Data Repository
Open-source implementations of openEHR that can be utilized to set up a Clinical Data Repository are [17]: EHRbase was used to set up the CDR. To set up the EHRbase server a docker was used. A docker-compose file was created in which an EHRbase image was used 10 (ehrbase:0.16.5). The database container had to be set for EHRbase. There are two ways to achieve this, the simplest is to utilise an ehrbase-postgres image provided by EHRbase, which does not require manual configuration. Alternatively, a base Postgres image can be used but it has to be configured manually. We used the latter method therefore migrations needed to be added manually as a normal Postgres image was used as opposed to an image meant for EHRbase. The file cloud-db-setup.sql was used from the EHRbase Github repository to set up the database. The docker instance was then started and then the server was set to run at port 8080 for testing purposes.

Posting Templates to the CDR
The template exported from Archetype Designer in XML format was posted to the EHRbase server using API endpoints provided by openEHR [19]. Insomnia was used for this purpose, a GET request was posted to the endpoint with the body as the template in XML format. As an alternative option Spring boot UI can also be configured and the user interface provided by it can be used to make API requests.

Demographics Data
Demographic data like Name, Contact Number or Aadhaar Number for each patient is needed by clinics and hospitals but to ensure clear separation from the clinical data they are not stored inside an openEHR system by design [18]. Therefore a custom solution can be used for storing the demographic-specific data of a patient and then a reference to the EHR would be stored in the database.

RestAPI for Demographics Data
MongoDB was used to store the demographic data of patients. MongoDB is a NoSQL Database, which means it stores data in JSON-like documents which are self-contained [20]. This makes MongoDB extremely scalable and perfect for this application. The schema shown in [ Fig.5] was used to make the REST API demographics data in MongoDB.

FHIR Patient Resource for Demographics Data
An alternative to using a custom database is using a FHIR (HL7) Patient resource to store demographic data of patients [21]. FHIR (Fast Healthcare Interoperability Resources) is an electronic healthcare information exchange standard. FHIR provides us endpoints for posting resources to their server. The patient resource in the FHIR specification is in Normative state, which means that the resource has been deemed stable and while changes to the resources are possible, they are expected to be infrequent and are tightly constrained [22]. 13 Fig. 9. The resource content for patient resource in FHIR A patient resource containing identifier, gender, name, etc can be created in the form of XML or JSON by referencing the Resource Content provided by HL7 website. This resource can then be posted to the patient resource endpoint. If the resource is successfully posted, a response JSON is returned from the server. An id can be extracted from this response JSON and can be used to create a new EHR with the same uuid using PUT request. Thereupon, we have linked the patient's clinical data in openEHR server with their demographic data in the FHIR server.

Deletion of Patient Data
When a composition is posted to the EHRbase server using RestAPI, all attributes inside the composition are checked and validated in accordance with the constraints and regulations defined by the archetypes and the template. After passing all tests, the data is indelibly stored in the EHR of the patient. The composition can only be updated, but cannot be physically deleted as electronic health records require a full audit trail about the patient data [18]. 14 In order to logically delete the Patient's data from the clinical data repository, we deleted or cleared the patient's data from the custom database solution used to store the demographics data. Once the reference to the EHR UUid is deleted, then the electronic health record cannot be accessed, thus it is logically deleted and lost forever.

Creating EHR and Posting Compositions
Two forms were created to register a patient. The initial form takes demographic data as input from the user : On submission of the form, an API call was made to the EHRbase server to create a new EHR. The uid of the newly created EHR was extracted from the response header and another POST API call was made to the MongoDB server for storing the demographic data. If no errors occur, the second form is displayed. This form focuses mainly on the clinical data of the patient. After submission of this form, an axiom POST request was made to the EHRbase server to post the composition of the patient.

4.6
Querying Data Using Archetype Query Language

Overview
Archetype Query Language (AQL) is a query language developed specifically for expressing queries used for searching and retrieving the data found in archetype-based repositories. This is a very good way to query hierarchical data [23]. Already existing query languages like SQL, OQL, etc. cannot be used to query archetypes in such systems. The reason for this is the aforementioned Query Languages have dependencies on specific data schemas and physical representations like relational tables for example. For writing a valid query, the user must be familiar with the data schema of a particular database. Thus, a query written for one schema is not sure to work on other systems.

Syntax for writing AQL queries
The Archetype Query Language (AQL) consists of 5 clauses : • Select : The data elements to be returned are specified by this clause • From : The source and the containment criteria are specified by this clause • Where : The criteria for data within the source is defined by this clause • Order By : The order of the returned set is specified with this clause • Limit : The result set is limited to particular number of items by this clause Clinical data of a particular patient can be retrieved from the Clinical Data Repository by writing AQL queries with a WHERE clause to specify the EHR Universally unique identifier (UUID). Clinical data can be queried based on the Composition mirroring a template or Observations, Evaluations, etc. This method is preferred as it significantly increases semantic interoperability and fetches data without being bound by specific templates.

Implementation
After Electronic Health Records were created and compositions were posted to the EHRs, to display patient data to users we have to retrieve compositions from the EHRbase. AQL queries were used to query compositions from the openEHR system. When the aadhaar card number of a patient is entered, a GET request to the demographics server to retrieve the Electronic Health Record reference (EHR reference). This reference is then used to retrieve compositions from an EHR using AQL queries.

Discussion and Conclusion
COVID-19 brought about a situation of panic and fear across the Indian subcontinent in 2019. Many lives were lost and a significant number of people suffered permanent damage to their organs due to this pandemic. As hospitals upgrade to new and better technologies, attention should also be directed towards the usage of HealthCare standards. These standards establish interoperability in different contexts, allowing communication with external applications [24]. An interoperable system similar to the one made by us can be used successfully for storing the Covid data of a patient using openEHR standards. Data of a patient can be retrieved when needed. Multiple hospitals and clinics can use this system to access and refer to a patient's medical history even if he was treated at a different hospital, which could aid them in