With this work, we demonstrate SALUS Patient History Tool which presents patient summaries to the clinical researcher by retrieving the values of the patient data fields from the semantic instances which come in the form of SALUS Common Information Model. The tool makes use of the SALUS Common Data Elements to extract the corresponding data from the semantic instance before presenting to the researcher. In addition, this work demonstrates the use of the IHE DEX profile in clinical settings for a real world scenario coming from the SALUS project.
A Common Data Element (CDE) can be defined as the smallest meaningful data container in a given context/domain which are defined in a structured and standard way in order to improve data quality and promote data sharing; hence interoperability. In eHealth, especially in clinical research, the benefit in adopting CDEs in information systems for the sake of data interoperability is well recognized. The objective is to reduce start-up times and accelerate data sharing among clinical investigators [1]. Many efforts are trying to facilitate interoperability in eHealth by defining CDEs as referred by Sinaci et al [2].
CDEs are defined in several granularities by several organizations. In clinical research, CDEs for data collection have been developed for various disease domains. One important source for this is the National Institutes of Health from the U.S. As stated by NIH [3], the use of CDEs in clinical research, patient registries and other human subject research is encouraged in order to improve data quality and opportunities for comparison and combination of data from multiple studies and with Electronic Health Records (EHRs).
SALUS project [4] aims to provide a standard-based, semantic interoperability platform integrated with a number of safety analysis tools for post market safety studies. SALUS addresses the challenge of re-using EHRs for clinical research activities. For this purpose, SALUS has developed an information model and a set of CDEs each of which can point to the physical information model. SALUS has defined 199 CDEs and a SPARQL script has been developed for each CDE as its extraction specification [2] pointing to the SALUS Common Information Model.
SALUS CDEs are maintained within the SALUS CDE Repository which is based on the Semantic Metadata Registry/Repository (Semantic MDR) [2]. Apart from maintaining the SALUS CDEs; since the Semantic MDR is an implementation of the IHE DEX (Data Element Exchange) [5] profile, it can also serve the extraction specifications (hence the SPARQL scripts in this case) for those CDEs through a standard web service interface.
During post market safety studies, signal detection is performed on the collected Individual Case Safety Reports (ICSRs) by the clinical researchers. A thorough clinical assessment of these reports is performed to catch signals for possible adverse drug events. At this step, access to information in the patient histories beyond what has been entered on the case report form adds more power to the analysis, which is not possible now [4]. Clinical researcher may want to go back and review the entire patient history, including prescriptions and diagnoses which are not extracted to the ICSRs according to the respective specification. In this work, we demonstrate the SALUS Patient History Tool which presents patient summaries to the clinical researcher by retrieving the values of the patient data fields from the semantic instances in the form of SALUS Common Information Model with the use of the SALUS CDEs. In addition, this work demonstrates the use of IHE DEX profile in clinical settings for a real world scenario coming from the SALUS project. CDE Repository plays the role of the Metadata Source while Patient History Tool acts as the Metadata Consumer of IHE DEX profile [5]. 2
SALUS Patient History Tool
Patient History Tool has the unique identifiers of the CDEs to be presented to the clinical researcher. After receiving a patient summary from SALUS system by providing ICSR related identifiers, the tool interacts with the CDE Repository for each CDE to receive its extraction specification. This interaction is performed through IHE DEX profile. The extraction specifications are SPARQL scripts because SALUS semantic interoperability layer returns patient summaries as RDF instances conforming to the SALUS Common Information Model ontology. For each CDE, corresponding SPARQL script is executed on the patient summary and data for that CDE is extracted from the patient summary. The tool provides a powerful navigation mechanism to conveniently present this data to the researcher. Fig. 1 depicts a flow to illustrate this process.
Patient History Tool is a fully web based utility which can run on any web browser. Fig. 2 presents a snapshot of the tool at the time of navigating through a patient summary. It has been designed and implemented with HTML5 principles; using Javascript and RESTful interactions. Additionally, the tool communicates with SALUS CDE Repository (which is based on the Semantic MDR [2]) through IHE DEX RetrieveMetadata [5] transaction whose web service has a SOAP binding.
SALUS defines 199 CDEs together with their extraction specifications. Patient History Tool has been designed and implemented to present all these CDEs while easing the navigation with the use of latest web development technologies. Since it interacts with the semantic SALUS system and extraction specifications are SPARQL scripts as a consequence of this; Patient History Tool is inherently semantic aware.
Implementing the Metadata Consumer role, Patient History Tool demonstrates the use of IHE DEX profile for the patient history navigation use-case in SALUS which reflects a real world setting. CDE Repository maintains all SALUS CDEs and extractions specifications are retrieved from the repository through IHE DEX based web service calls.
The use of SALUS CDEs which are maintained in a Semantic MDR (i.e. SALUS CDE Repository) can be exploited further to increase data interoperability for study feasibility, patient eligibility and recruiting (i.e. clinical trial form design), adverse event reporting, security and privacy related operations (de-identification & pseudonymization), retrospective observational studies as well as case report form prepopulation. In addition, use of extraction specifications for the CDEs increases the level of data interoperability inline with the adoption of document export standards such as ASTM/HL7 CCD and Consolidated CDA (where XPath scripts can be used as extraction specifications).
Acknowledgements. The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007–2013) under Grant Agreement No. ICT-287800, SALUS Project (Scalable, Standard based Interoperability Framework for Sustainable Proactive Post Market Safety Studies).