Clinical relevant information about patients is stored in different locations and often hardly accessible for medical doctors and researchers. The treating doctor needs access to all available data from di erent sources, because not just locally available data but also data in remote locations and the relationships among di erent resources are relevant for patient care, e.g., the in uence of a heart-rate on the medication intake. In this paper, we propose an approach for integrating FHIR (Fast Healthcare Interoperability Resources) for medical doctors' or researchers' unique needs/questions without changing the original data generated during a clinical medical process. Our approach combines semantic technologies, RDF (Resource Description Framework) data and OWL (Web Ontology Language) ontologies, with the medical standard FHIR, to transform medial information in a semantically annotated knowledge graph. The medical knowledge in the resulting graph is for the consumer (who needs the generated data) and for services of a \Distributed Medical Rule Engine" (DMRE). The service takes care of retrieving the information from di erent FHIR-stores, but also on the transformation to an RDF-graph. The resulting RDF-graph contains the clinical medical data, and also the connections between the entities. The knowledge graph contains applicable information for either a treating doctor or a researcher who, e.g., needs to explain observations and discover not-yet-explainable insights.
Clinical medical information about patients and the population is highly relevant
for physicians and medical researchers to nd new ways of treating diseases [
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Considering the relevance of selected data sets and their relations and correlations is di erent for every medical researcher, an approach is needed to rstly allow a researcher to get the required information depending on the research context, secondly from multiple sources, and thirdly in an interoperable way to enable further processing. By now, data collections out of medical research studies are siloed within one organization and focused on the speci c need of the research question. An integration from clinical data, generated during routineexamination is, for many reasons (e.g., data-protection, legal aspects, particular needs, ethical aspects), not done. An approach for a standardized, interoperable distribution of clinical-routine-data is required (usage for retrospective studies). Such a method can also be integrated into point-of-care information systems to allow a physician a more detailed view of patient's information.
Since data is already existing in various sources and is (partly) available for
retrospective studies, the problem to be addressed is the digital curation of
single unique data sets containing medical information and relationships to create
value for either a doctor or a researcher. Retrospective data collection is
especially useful when investigating factors that contribute to limited events and not
yet known research questions since data may be collected from various sources.
Moreover, retrospective data collection is less expensive than prospective
collection [
In this paper, we contribute by practically implementing a semantic curation approach enabling the semantic mapping and ontological enrichment of secondary medical data in FHIR-format into a RDF-knowledge graph. During the semantic mapping into RDF the input FHIR-resources are enriched by an ontology that semantically represented the particular research needs. This means we semantically curate existing medical data and information about a patient to provide a medical researcher with new information or aspects of the existing data. For example, a laboratory only creates test-results. However, for the overall information about the patient there is corresponding information missing like blood-group, medications, or diagnoses. All this information together has a high impact on the laboratory-result, the diagnoses, and most important, also on the medical therapy.
This paper is structured as follows: in Section 2 we describe background and related work providing information about FHIR and RDF and the prerequisites for the targeted solution. The solution-section (3) describes the technical and implementation details. Section 4 describes an example use case. We evaluate the solution in Section 5 and discuss it in 6. Finally, we conclude this paper with the pros and cons in Section 7.
We contribute by translating FHIR into RDF and enrich the semantics of the resulting RDF knowledge graph with ontological knowledge (OWL ontology) during the curation process.
FHIR (Fast Healthcare Interoperability Resources) is an HL7 (Health Level
7)Standard framework, which is based on modular components called resources.
It supports RESTful architectures and is based on web-standards such as XML,
JSON or HTTP and OAuth (Open Authorization) [
The Resource Description Framework (RDF) is a standard model for data
interchange on the web [
The Web Ontology Language (OWL) [
The input for processing of FHIR-data into RDF is the generated raw-data
during clinical routine processes. Today's hospital information systems (HIS)
use healthcare standards like HL7- Version2 (text-based), HL7- Version3
(using a formal methodology de ned in the HL7 Development Framework HDF),
or HL7-FHIR. There are di erent use cases and aspects in a healthcare
environment, which need consideration to nd the correct store-location for health
information. First, there are patient-centered aspects which are critical for
individual patient care. Secondly, there are legal viewpoints, and a third aspect
are clinical-medical research topics. For patient-centered issues, this means that
an interoperable infrastructure is needed for patient treatment and doctors'
collaboration, as described by \Integrating the Healthcare Enterprise" (IHE). Such
an infrastructure can also take care of the legal aspects, and since the
IHEmodel is patient-centered, it is used for medical treatment. IHE also provides
an approach for research covered in the \Quality, Research and Public Health"
domain [
FHIR-resources can be accessed by HTTP-requests and the queries can be
adapted to address the information requests of a consumer. Using direct
communication has a disadvantage: a consumer can not query multiple stores at the
same time (and even get just a single FHIR-resource at a particular time), and
the consumer needs exactly to know, where which needed resource is located in
terms of endpoints (FHIR-servers). Secondly, it returns single FHIR-resources
or FHIR-bundles (by using an operation called \Operation-patient-everything"
[
In medical research, there are multiple existing patient data collection
methods. Among these methods, there are \Retrospective record review", \Record
review of current inpatients", and \Key Informant Interviews" [
Another approach is using machine learning for data analytics to discover
valuable patterns by analyzing massive numbers of unstructured, heterogeneous,
non-standard, and incomplete healthcare data [
In our solution the user speci es the requirements of an expected or needed result. A speci c research question de nes the requirements that are relevant to the researcher. Necessary information could be, e.g., medication intake, blood group of a patient, or the age, or the outcome of a laboratory result. The requested information is semantically de ned within an ontology representing the relevant classes/concepts of the information domain and the semantic relations between them.
The de ned ontology expresses the classes, which are mapped from FHIRResources, while datatype properties related to the classes are the attributes of the FHIR-resources. The ontology's object- properties represent the relations to other classes (e.g., a \has Medication"- property). This speci c description allows the user to obtain a reduced dataset, with just the relevant content, or enrich the information available in the di erent FHIR-stores by relations.
Mapping-table (Table: 1) shows the general mappings from the FHIR-context
to the semantic context. The particular FHIR-resource (e.g. Patient) maps to a
de ned class in the ontology (owl:class). The FHIR-Resource-URL is mapped to
the RDF's subject, while the attribute and its values are mapped to the
RDFpredicate and the RDF-object. If the FHIR-Resource-Attribute-value is not of
type PrimitiveType (e.g., String, Integer, boolean)[
FHIR-Context
Semantic Context FHIR-Resource FHIR-Resource-URL FHIR-Resource-Attribute rdf:type Subject
Predicate
FHIR-Resource-Attribute-value Object
As shown in Figure 1, the consumer (e.g., a researcher) initiates a query (containing a patient-id) to an HTTP-Service located within a so-called \Distributed Medical Rule Engine" (DMRE). This DMRE is a component, which provides di erent services for performing SPARQL-queries, getting information from FHIR-stores and reading ontologies in OWL. After the initiated query, the DMRE calls the \OWL-read-service" to receive all the classes, attributes, and relations. This information is then used for speci c FHIR-queries at the di erent FHIR-endpoints. Speci c queries for the FHIR-stores are more e cient (in terms of timing) than \get-all-queries". Secondly, we process the returned dataset, and therefore reduce memory consumption by reducing to a speci c informationcollection. Once the FHIR-resources are returned to the DMRE, we generate an RDF-graph out of the information combined with the ontology de ned by the consumer. Consumer de nes Structure initiates Query return RDF
h Consumer get needed information query for relevant resources
return generate RDF-graph
FHIREndpoints
FHIREndpoints
For collecting all the information and making inferences about the information, we contribute with the following system architecture (Figure 2). At the top-level, there are three components: the Consumer, the Distributed Medical Rule Engine (DMRE), and the FHIR-stores.
The main component is the DMRE. The consumer initiates a query. The FHIR-stores hold the medical information. This medical information is de ned by HL7-FHIR and is provided via standard-HTTP-interfaces. The DMRE applies di erent services to collect information from di erent FHIR locations and to access the ontology knowledge. The services are: { ReadOWLAndAttachFHIR-Service { OWL-Read-Service { SPARQL-Service { FHIR-Query-Service
The ReadOWLAndAttachFHIR-Service is the central coordinator, which takes care of the correct work ow execution. It is a service, which receives requests from consumers, and returns the result. In the next step, the \ReadOWL AndAttachFHIR"- Service uses the OWL-Read-Service. The OWL-Read-Service parses the prede ned ontology, gets the classes, and uses a SPARQL-Service to get each de ned class's properties. These classes and properties are passed to the FHIR-Query-service. DMRE
HTTP1
read OWL File DataAccess
From a technical perspective, there are several essential elements. The dened ontology follows the Web Ontology Language (OWL), which is represented in RDF-syntax. The classes need to follow the HL7-de ned FHIR-resources. This means a Patient-resource in FHIR needs to have the same name as the class in the ontology. The same applies to elements in the resources. As an example, a datatype-property for \unit" should be de ned in the ontology by \valueQuantity.unit".
This is needed for parsing the FHIR-results for the speci c values, in order
to ll the RDF-graph. There is one issue: since we are using JSON-Path [
For reading the ontology and generating the RDF-graph, we are using the
RDF4J framework for processing and handling RDF data [
valueQuantity . value > < valueQuantity . unit xmlns =" http: // dmre /" > mmol /l </
valueQuantity . unit > </ rdf:Description >
Here we nd the URI of the FHIR-Resource, the type of the resource, as well as the de ned attributes - in this case, the ID, the unit, and the value of FHIR's Observation-valueQuantity. Finally, we store the result of the RDF-graph in a knowledge base in order to make it persistently accessible for later processing.
There also exists a proof-of-concept implementation, which is available on Github. There is also the initial ontology, as well as a resulting example provided. The code executes the process in the sequence-diagram by using the elements in the system architecture. 4
A medical doctor is supposed to retrieve all available observations from a patient to get an overall picture of his current patient. There are two necessary steps: rstly, the de nition of the needed dataset is given by the physician, and secondly, a manual trigger where a patient-id is sent to the DMRE-Service. For de ning the needed values in advance, a person, who has knowledge about FHIRdata-structure, is needed to capture the correct values. Additionally, there is a de nition needed to characterize the dependencies among the nal resources. In our example, the doctor is using the FHIR-Resources \Patient", \Observation", and \Medication". In the ontology, the doctor describes the relations \a patient has a medication", and \a patient has an observation". The attributes of the Patient-class (=Patient-FHIR-Resource) are: \ID" and \name". For the Medication-class (=Medication-FHIR-Resource) it is \ID". For the Observationclass (=Observation-FHIR-Resource) the doctor likes to have the attributes \id", \value", \unit", \e ectiveDateTime", and \code.coding[0].code". These prerequisites end up in an ontology provided as an ontology- le represented in XML.
Based on this ontology (which is the same for all Patients), the medical doctor can now trigger a request, having the Patient's ID. Figure 3 shows that the user https://github.com/gkober/ReadOWLAndAttachFHIR provides the patient's ID in the web-interface and the ontology that should be applied. The result after processing is displayed in the textbox and contains the complete generated RDF-graph.
For the doctor, the complete process is transparent since the doctor only knows the patient-id, but the DMRE queries all endpoints providing information about the patient (with this patient-id). The result is not yet ready for use by a medical doctor, but it provides the technical data basis for e.g. further evaluation and further queries or for generating a graphical overview of the patient's data. We evaluated three crucial aspects: Firstly, the completeness of the result. Secondly, the contents of the resulting RDF-graph and as third aspect, its size. The evaluation was done using di erent samples of a public HAPI-FHIR-test server (http://hapi.fhir.org/baseR4/). # Entries FHIR-server Entries RDF-Graph Size-FHIR-Resources Size-RDF-Graph 1 1 1 3 kB 4 kB 2 36 36 55 kB 28 kB 3 45 45 69 kB 34 kB 4 56 56 86 kB 41 kB 5 64 64 100 kB 46 kB
The result's completeness: we crosschecked the amount of FHIR- resources to the number of resources converted in the RDF-graph. In comparison, we found the same numbers for both (see. Table 2). This means, during conversion, no data set from the FHIR-server gets lost, and all resources belonging to a certain patient are taken into account.
Analyzing the contents of the RDF-graph was a manual and visual task.
We compared the nal RDF-graph with the expectations of the initial ontology
and if all the given properties were translated correctly from the FHIR-resource
to the graph. The visualization was done using OWLGrEd [
With respect to the size of the resulting RDF knowledge graph: the FHIRresources itself only needs a few kilobytes. By using the DRME, applying an ontology, and only selecting the data needed for speci c questions, we were able to reduce the number of bytes. This data size reduction bene ts the data transmission to the client, which needs to parse the result and display it for the end-user. As we can see in Figure 4, the sizes of the data packages in the RDFGraph are less than the original FHIR-resources. The explanation for having a greater size in the RDF-graph in comparison to the FHIR-resource (in case of one entry) is, the additional data of the ontology-knowledge in the graph. Although there is a higher count of entries in the result, the size of the RFD-graph is still reduced because the client focuses on only a few interesting properties of an FHIR-resource.
The solution presented in this paper semantically creates a RDF-graph by querying data values from various FHIR-resources and semantically curating and mapping these values into an ontology representation. The proof of concept implementation reads the manually generated ontology, while a consumer can trigger the RDF generation by using a ReadOWLAndAttachFHIR-Service from the Distributed Medical Rule Engine (DMRE). The ontology for the PoC contained classes for Patient, Observation, and Medication, and a subset of attributes for these classes.
We tested the approach in two scenarios: Firstly, the initiating query for evaluation is asked for only one patient having one observation. This simple task allowed us to manually check for the newly generated individuals and evaluate if they were set correctly. Secondly, we choose di erent patients having up to 64 observations. This also resulted in an RDF-graph with the needed instances and correctly translated medical information.
The approach is patient-centered, as we wanted to collect all information from di erent FHIR-stores. This might have limitations in case of other research questions, e.g. a research question could be about the whole patient-population (e.g., a particular illness). Here the ontology approach works in the same way as the patient-centered use case. However, the FHIR-queries on the FHIR-stores need alignment within the software.
Useful is the option to de ne which attributes of an FHIR-resource are needed. For example, de ning the patient-resource without names can lead to anonymization, which is essential for research-data. Another aspect is, the ontology for the resulting graph can be aligned until a consumer has the needed data-collection as required. The limit is in the availability of the information stored by doctors, hospitals, or patients. For example, if a patient provides his pulse-rates, a researcher can get this information (if not denied by security mechanisms, like authorization). 7
In this work, we proposed a semantic mapping approach that creates and curates a medical RDF-graph taking standardized FHIR-resources of daily clinical routine-processes as input and uses an ontology for semantic knowledge representation in the RDF graph. The consumer de nes the information needs for the particular use-case (or research-question).
The solution can reduce and extend the amount of data according to the consumer's needs. If only some values from the FHIR-server are needed, we can provide a simpli ed data-structure but with the bene ts of an RDF-graph. Therefore a consolidated view on the data is provided for answering research questions. If technical and legal access is granted, the patient's private information is also available in the RDF-graph. In theory, the generation-process (and the de nition) allows us to form an anonymized RDF-graph. This advantage needs further investigation if it ts the needs of an anonymized data set.
Future research might apply SPARQL-queries to the resulting RDF-graph to specify the researchers' needs over the dataset. These queries could answer critical questions from researchers. Furthermore, the generated RDF-graph can be enriched with other graphs/ontologies to get more information for patients' treatment or public health questions (e.g., attaching a FOAF (Friend-of-a-friend)Ontology).