A SOA-Based Platform to Support Clinical Data Sharing

Abstract

The eSource Data Interchange Group, part of the Clinical Data Interchange Standards Consortium, proposed five scenarios to guide stakeholders in the development of solutions for the capture of eSource data. The fifth scenario was subdivided into four tiers to adapt the functionality of electronic health records to support clinical research. In order to develop a system belonging to the "Interoperable" Tier, the authors decided to adopt the service-oriented architecture paradigm to support technical interoperability, Health Level Seven Version 3 messages combined with LOINC (Logical Observation Identifiers Names and Codes) vocabulary to ensure semantic interoperability, and Healthcare Services Specification Project standards to provide process interoperability. The developed architecture enhances the integration between patient-care practice and medical research, allowing clinical data sharing between two hospital information systems and four clinical data management systems/clinical registries. The core is formed by a set of standardized cloud services connected through standardized interfaces, involving client applications. The system was approved by a medical staff, since it reduces the workload for the management of clinical trials. Although this architecture can realize the "Interoperable" Tier, the current solution actually covers the "Connected" Tier, due to local hospital policy restrictions.

Figure 1

The harmonization algorithm.

Figure 2

The designed and implemented architecture for the management of clinical trials on patients affected by infectious diseases. The light yellow box represents the solution to support the “Interoperable” Tier (adoptable after Ethical Committee approval), while the dark yellow box shows the system which is currently working (“Connected” Tier). Blue arrows represent the standardized call to web services, while red arrows represent not standardized communication adopting property formats. The additional information under the dark yellow box provides technical details about the solution that the authors designed and developed to connect the IXS and RLUS web services with the existing systems.

Figure 3

Sequence diagram of a patient's enrolment. The content inside the curly brackets refers to the blue arrows reported in Figure 2. The second subscript letters distinguish the call (C) of specific web service functions to the response (R).

Figure 4

Sequence diagram of run-time analysis of clinical information. The content inside the curly brackets refers to the blue arrows reported in Figure 2. The second subscript letters distinguish the call (C) of specific web service functions to the response (R).

Figure 5

Sample extract of a SOAP request which contains the RLUS object to map the filter criteria.

Figure 6

Example of a SOAP message traced during the second interaction of the diagram represented in Figure 3 between the PAS Desktop Application of a hospital involved and the PIS node service.

Figure 7

Sequence diagram of the daily automatic update of repository of CDMSs/registers. The content inside the curly brackets refers to the blue arrows reported in Figure 2. The second subscript letters distinguish the call (C) of specific web service functions to the response (R).

Figure 8

The temporal evolution of the project.