The methodology to design and develop the interoperable platform had six well-structured stages (Textbox 1): (1) creation of a minimum data set to report the PCR SARS-CoV-2 tests, (2) modeling processes and end points where institutions interchange information, (3) standards and interoperability design of the FHIR, (4) software development, (5) software testing, and (6) software implementation.

The first stage to communicate the results between laboratories and the Chilean government was constructing a minimum data set to share the information (Figure 1). The collaboration was essential for the meeting, discussing, and consenting to fulfill the minimum data set needed from the PCR SARS-CoV-2 tests to track and develop scalable and interoperable solutions. In this sense, we met with most of the laboratories that process PCR tests for COVID-19 in Chile. In three online sessions, the institutions discussed the importance of streamlining data and the report’s fields. This group designed and documented the name, data type, cardinality, and possible extensions of the fields. 

The modeling of the process is an essential component for interoperable development [14]. It is necessary to understand the process and end points where information between the institutions is interchanged. We used the Business Process Model and Notation (BPMN) [20,21] standard using the free software Camunda Modeler (Camunda Services GmbH) [22]. The diagrams were kept in a web-shared directory and were shared by Cawemo (Camunda Services GmbH) [23], a web application focused on the collaborative editing of BPMN diagrams. This software allows for the creation of projects with the possibility of commenting on elements, exporting and importing, and sharing them with other users differentiated by roles, enabling real-time monitoring and visualization of the latest version of the diagram.

Once the minimum data set was defined, the process modeled, and the end points detected, the following stage adopted standards and interoperability design. In this phase, we worked with FHIR Release 4 [16]. HL7 developed FHIR as an interoperability standard designed explicitly for web-based exchange and improved its capabilities with emerging web standards such as REST interfaces [14]. FHIR solutions are constructed from a set of modular components called “Resources” [24]. All resources have references to other resources, extensions, and human-readable extensible HTML displays.

FHIR is the evolution of interoperability standards from HL7 [14,24]. The principles of modern web and mobile development make FHIR malleable and adaptable to new technologies. Compared with other document-centric standards, HL7 FHIR takes a modular approach by exposing the health data entities as services using HTTP-based REST and API. Furthermore, FHIR is more comfortable for implementing the design of the solution for clinical and nontechnology professionals. The resources are human-readable with a modular approach, representing the atomic and granular health care data (eg, patient, procedure, medication, observation, and practitioner). FHIR’s architecture supports the inclusions of decision makers, doctors, and laboratory workers among other profiles.

The platform’s methodology considered professionals’ participation from a wide spectrum of areas in the interoperability design level (Textbox 1). They selected the data, discussed the process, and finally validated the standards adopted. HL7 FHIR helped include clinicians and laboratory decision makers in the process.

In this stage, we matched the defined minimum data set with FHIR. An FHIR-based system’s capabilities were selected by considering which resource was the most adequate from a clinical perspective. These resources can be easily assembled into working systems that solve real-world clinical and administrative problems [14]. For modeling these relations between resources, we used the clinFHIR graphBuilder application [25]. This online tool allows for the assembling of resource instances into a graph of connected resources that represent a specific scenario with FHIR.

The requirements from the laboratories’ providers and the Chilean government were divided into functional and nonfunctional. This phase is a critical aspect because it lays the foundation for all the software, affecting the development later in the project [26]. All functional requirements are the features the web platform will perform, such as sharing the laboratories’ tests, tracking them, and storing them safely by the Chilean government. Nonfunctional requirements describe how the web platform should behave, such as security, interoperability, and performance [27,28].

The software was built separating the layer from the data model and the business logic. Figure 2 shows the software architecture and technologies employed. Interoperability and security are critical nonfunctional requirements for interoperable development [14]. Moreover, the application considered a load balancer for http and https traffic, and a network load balancer for load balancing Transmission Control Protocol traffic.

The persistence (storage) was designed with two balanced mirror servers (Figure 2). This layer stored the data in a MySQL V 5.7 (Oracle Corporation) database, and the resources were stored within the HAPI FHIR database. The HAPI FHIR server V5.1 had the responsibility of the interoperability layer [18]. The HAPI FHIR library is an implementation of the FHIR specification for the Java programming language. The authentication layer was configured with JSON Web Token (JWT), an open standard [29] that defines a compact and self-contained way for securely transmitting information between parties using a JSON object.

The security infrastructure was managed by the Ministry of Health’s private network, which was outsourced to a telecommunication company. The company assumed the management and maintenance of the communications network, which includes more than 1500 health establishments throughout the country, including 120,000 voice points (telephones); 30,000 email boxes; and 200 videoconference rooms. The laboratory that participated in this platform was connected on this secure network [30].

Moreover, FHIR is suitable for use in the application layer for a broad context: mobile apps, cloud communications, electronic health care record–based data sharing, and server communication in large laboratory providers [16].

Software testing was focused on functional and nonfunctional requirements. The functional requirements were obtaining the data and sharing the laboratories’ tests using FHIR, tracking PCR SARS-CoV-2 tests, and storing tests with the Chilean Ministry of Health.

The nonfunctional requirements such as performance and security are essential in health care information systems [18], such as maintaining the accuracy and completeness of the information exchanged with confidentiality and privacy. Moreover, the interoperability was the core of the solution, basing its structure on FHIR. Considering all of these issues, we proposed the catalog of nonfunctional requirements [28] by adapting the tree structure for an interoperable development (Figure 3).

We have implemented the platform with the UC Christus laboratory. This is primarily because they process the PCR SARS-CoV-2 tests for the “Esperanza” Project [31], a collaboration between public and private institutions to test and track COVID-19 cases in Chile.

It is critical to build a comprehensive implementation guide [14]. This guide sets rules for how an interoperability problem should be solved by employing FHIR resources. For creating the implementation guide using FHIR resources, we used the platform Simplifier.net [32].

The minimum data set was created from the stakeholder analysis and could extend its use beyond the COVID-19 pandemic. Table 1 summarizes the consented data set (see Multimedia Appendix 1).

The diagram created represents the complete process for obtaining the data and sharing the laboratories’ tests with FHIR, tracking PCR SARS-CoV-2 tests, and storing tests by the Chilean government. Moreover, the process identified the end point where the institutions share information (Figure 4).

The match between the minimum data set and FHIR is shown in Table 2. Each field is matched with the resources identified from FHIR. Table 2 lists the resources used for this solution.

With the clinFHIR modeler, we created a graph view (Figure 5). Each resource instance is represented by a rectangle containing the title and type, and references are represented by arrows (references are directional). Connecting the resources is the heart of FHIR. In this way, a complex scenario can be represented by several simple building blocks (much like the way that Lego bricks can be assembled into complex shapes). In FHIR, this process is called references, and a reference always goes from one resource to another.

The agile methodology is characterized by having light and evolutionary documentation. The design documentation (BPMN process, list of requirements, match standards, database model, and sequence diagrams) is necessary to document and follow the platform’s development.

The development of the proposed architecture began with the configuration of the security layer (Figure 6). This layer is responsible for managing the credentials for authorization and authentication of the valid users for accessing the HAPI FHIR server. The HAPI FHIR server was configured to develop two end points where the laboratories send the information and the Chilean government receives an FHIR message. Following this, we created profiles for each resource. An FHIR profile is a set of rules that allow an FHIR to be constrained or include extensions to add additional attributes [34].

At the end of this stage, we generated the message container (Bundle) with the list of the resources with the HAPI FHIR library (Figure 7; to review the complete Bundle, see Multimedia Appendix 2).

Software testing was focused on testing both functional and nonfunctional requirements. The functional requirements were tested with the critical features that an interoperable web platform should have. In this sense, three functionalities were measured: (1) obtaining the data and sharing the laboratories’ tests with FHIR, (2) tracking PCR SARS-CoV-2 tests, and (3) storing tests with the Chilean government (Table 3). The FHIR and conformance statement testing used the entire bundle (Figure 7) with all the resources linked (Figure 5) with the JSON format. Each bundle sent is considered an atomic result of a PCR test belonging to one patient from UC Christus Laboratory to the Chilean government.

Nonfunctional requirements were tested considering the classification previously described (Figure 3). Table 4 lists the testing information, with the description and formulas used to calculate each result.

A private secure network managed the security infrastructure. The laboratory was connected by a virtual private network (VPN) with the Ministry of Health. For this solution, we used the VPN for sending bundles (with all the resources involved).

For the authentication and authorization, the platform was implemented through the API gateway with valid credentials and the right access control list. This involves a set of rules or a promise usually executed through agreements that limit access or place restrictions on certain types of information. The authentication was implemented with the JWT with an expiration time, verifying the person’s or device’s identity.

The integrity was tested considering accuracy (number of mistakes that a failure detector made in a certain period) and completeness (number of crashed processes suspected by a failure detector in a certain period). We obtained (Table 4) a platform with strong accuracy [35] since each stored record could be traced back to its source and the messages were completed [35]. This is because each valid request received is processed and stored.

At the beginning of the implementation, a load test with 1000 requests was processed in 35 seconds. The response was under 216.7 milliseconds 50% of the time, and 90% of the time, these response times were under 323 milliseconds. The minimum and maximum response times were 118 milliseconds and 2806 milliseconds, respectively. The platform could process 28.3 requests per second. There were zero request errors. Following previous results, the solution would report 10,000 PCR SARS-CoV-2 tests in roughly 6 minutes.

The standard documentation for this solution is open for the FHIR community [15]. The implementation guide was created with Simplifier [32] for adequately documenting the scope, architecture, minimum data set, process model, profiles, and examples with the Bundle.

In this paper, we have designed and developed an interoperable and scalable solution that uses FHIR to access and share LIS data for reporting PCR SARS-CoV-2 tests to the Chilean government. This initiative was proposed as a use case to demonstrate the feasibility and efficiency of interoperability between heterogeneous health care information systems. The contribution was focused on supporting efficient communication in the context of the COVID-19 pandemic, collaborating with Chile’s strategy.

The WHO recommends the TTI strategy as actions that are central to containing the COVID-19 pandemic [3]. In this sense, the Chilean government has strengthened the national plan for the TTI of confirmed, suspected, and probable patients with COVID-19 and their close contacts. For this, the first two goals were the following: (1) expand the coverage of the PCR testing and bring testing closer to the community level and (2) reduce the time elapsed between detecting the positive case (by clinic or laboratory) and the epidemiological investigation [36].

To comply with the WHO’s strategy effectively and efficiently, it is essential to incorporate interoperability and information systems in the data processes involved. In this sense, we need to strengthen and make interoperable the data involved in testing and the subsequent notification to the government [37]. The LIS needs to incorporate electronic data communication via standard interfaces. This is a way to achieve efficiency and safety in laboratories that process the PCR SARS-CoV-2 tests. This means changing the current workflows that primarily require using one or more paper media, transcriptions, or copy and paste to transform raw result data into a report [9,38].

Multiple countries have had problems counting and knowing the exact number of people infected with SARS-CoV-2 [11-13]. There are various reasons and errors in the reporting of results, and a common factor is the lack of interoperability between health information systems. Approaches aimed at sending spreadsheets via email expose patients’ privacy, increase the probability of error in retyping, and generate a delay in the notification of results [11]. The involved systems lacked an interoperability strategy to address the pandemic. The data would be reported correctly if they were not retyped in different health information systems [39]. This contribution looks to alleviate health care personnel from repetitive and administrative tasks via digitalization and automation using FHIR. This reporting platform significantly streamlines sample processing and reduces turnaround time. These features are also beneficial after the initial phases of the COVID-19 crisis.

Interoperability in health care information systems has been a hard and slow process [14]. During the last decade in Chile, health information systems’ proliferation has been extensive [40]; however, each system has become a silo, cut off from other institutions [39,41]. When data must be exchanged, it is done in an ad hoc manner without standards. The COVID-19 pandemic has accelerated many digital processes incorporating essential requirements for online communication into the ecosystem. Among them is the need to interoperate between health information systems.

The interoperability area at CENS, in collaboration with Chilean laboratories (public and private), has supported a testing and traceability strategy within the “Esperanza” project [31]. In this context, CENS is promoting the development of tools and initiatives that encourage the interoperability of health information systems, making it possible to advance toward better integration and traceability for health information at the national level.

The main result of this collaboration was the development of an interoperable HL7 FHIR platform to report PCR SARS-CoV-2 tests from laboratories to the Chilean government. This contribution was centered on supporting interoperability and communication with international standards (HL7 FHIR). The described interoperable platform aims to support the efficient reporting of PCR tests with FHIR from all the national laboratories to the Chilean government. The international standards for interoperability for reporting PCR SARS-CoV-2 tests applied in our platform could be applicable and scalable in other countries, contributing to interoperability in health care information systems.

This platform was developed for the Esperanza COVID-19 Project [31]; however, it is a public good available to all who wish to use it.

The testing and implementation phases were applied with the back-end configuration described in the Methods section.

The prior work developed for reporting PCR SARS-CoV-2 tests from laboratories to the Chilean government was built ad hoc without standards. We made a brief comparison with the preceding solution used and found the following: the prior work does not use interoperability standards (web services–based solution), the response time of the preceding work was higher than 681 milliseconds (three times more), and a simple token managed the security without an expiration time.

The FHIR platform for reporting PCR SARS-CoV-2 tests from laboratories to the Chilean government was implemented online and is currently being used with UC Christus Laboratory.

The platform was tested and implemented adequately. On average, 1000 PCR SARS-CoV-2 tests are processed in 35 seconds, with confidentiality, secure authorization and authentication, and message integrity.

This platform simplifies the reporting of PCR SARS-CoV-2 tests and contributes to reducing the time and probability of mistakes from counting positive cases.

The interoperable solution with FHIR is working successfully and is open for the community, laboratories, and any institution that needs to report PCR SARS-CoV-2 tests.