Medical information exists in multiple locations (e.g., di erent hospitals, cloud services), but a complete collection of data is essential for high-quality healthcare treatments. Collecting information, annotating it with additional knowledge depending on the patient's observations, and building a reasonable dataset for further processing in decision support systems focus on this work. Previous work did not yet address the eld of Fast Healthcare Interoperability Resources (FHIR) combined with other ontologies, or creating an RDF-graph with the context-related information as the medication. By using semantic technologies like RDF and OWL, we propose refactoring and recreating the existing data by transforming it into an RDF-graph with RDF-annotations. By creating an architecture for the data collection and a proof of concept implementation, we experimented with samples from a public FHIR-store for the generation of the RDF-graph. This work shows the aggregation of FHIR-resources with medication information, which gets adapted for further processing in a semantic reasoner. Therefore multiple patient-related queries need to be done to gather all the available information, but also SPARQL-Queries for speci c medication information. The context inuences the result so that a di erent setting a ects the outcome of the RDF-graph.
RDF
Access to health information and an almost complete view on patient's data is crucial for e cient healthcare. Patients and doctors store information in di erent locations (e.g., di erent hospitals and various health-data stores). Medical knowledge is available in medical ontologies (e.g., Uni ed Medical Language System, SNOMED-CT). Combining relevant information from health-data and medical knowledge is required for automated decision making.
The relevance of information depends on the use case, and therefore the queries need to be aligned. So, if a patient needs to be alerted about medication intake to lower the heart rate, the focus is only on all heart rate observations from the di erent store-containers. The other needed information is about medication intake. Also, the knowledge about the medication is needed (e.g., causing e ects).
For evaluating the outcome of the queries and the combination of these results, the context is essential. The result is a "view" for a speci c use case, but it can change for other medical needs. These views are necessary since there is much information in di erent data-stores, which is not relevant to a particular question.
Because personal medical information is distributed and independent from each other, the information needs refactoring to describe dependencies. For this task, the generation of an RDF-graph is applicable, since it allows the representation of the dependencies between subjects (patients) and objects (observations). Furthermore, the RDF-graphs allows annotations 2
Medical information exists as Fast Healthcare Interoperability Resources(FHIR)
[
FHIR's medication administration resource "describes the event of a patient
consuming or otherwise being administered a medication" [
The reference to and from a medication administration resource is somehow
loosely coupled, as there is a reason-reference in the medication administration
as reason-support for a taken medication. The reason-reference in the data model
is optional. Therefore, an alternative way for the combination of FHIR resources
is needed. The time-items of each resource seems applicable because an
observation happens at a speci c time, where the medication administration has an
intake-time, and the medication itself has a physiological factor, called half-live.
According to [
FHIR already provides the transformation to RDF [
In [
Medical information always has a context. This context can be either the
meaning within it gets generated, or the background relevant for queries towards
existing knowledge. Context is highly proper when it comes to decision making
[
Since there is much information about the patient available in di erent locations, and not every observation is relevant for a particular use case, it is useful to reduce the data for answering individual queries. Suppose a doctor or even a patient is interested in extraordinary values from heart rates-classi cation. In that case, there is no use for the other observations like blood-pressures, oxygenation, blood-groups, and more. Therefore, the complete dataset's reduction is from a user's perspective, a needed task, as well from a data-processing perspective, in terms of memory consumption and optional data-transfers.
Another essential factor within medical observations and medications is the time component. As medicine can in uence medical observations just for a speci c time-frame, only the a ected values are interesting for further processing and decision-making. E.g., a patient takes medication to lower his heart rate, and this medication has a half-life of 10 minutes, all the heart rate-observations which are in between the intake-time and the end of the medication e ect are relevant (Fig 1). Depending on the use case, other time-frames are interesting or applicable for evaluation.
) 100 m (ebp 90 it u n rem80 sp ittaeb 70 n e trra 60 a e H
Period of Medication influence t+0 t+1 t+2 t+3 t+4 t+5 t+6 t+7 t+8 t+9 t+10 Time Relevant information for the medication-context-based use case can change because of the questions which need to be answered. There is more information to be taken into account if medical researchers ask for long-term medication e ects. If there is a need for an alerting-application, only a smaller amount of observations is important. Imagine a person taking heart rate lowering medication, and a smart device observes the person. The person wants to be alerted if the drug is not active anymore and only if the heart rate increases to a specied level, to repeat medication intake. This example shows that the relevance of information is given by the use case and takes care of the combination of other information sources.
Medication information consists of medication names, substances, dosages,
modes for application, frequencies, durations, reasons, and a narrative [
FHIR's medication-administration-resource [
Multiple sources provide information for the relevant overview. This information is available in di erent data formats. The representation of FHIR-resources is mostly JSON-objects, while the representation of ontologies is in RDF/XML. Aiming a complete view of all data also holding the dependencies among each other, which allows reasoning, leads to a graph representation. Therefore an RDF-graph is suitable for combining patient information, observations, and the corresponding medications with the extension of the medication's knowledge and the relations between the objects.
Moreover, RDF allows annotations to an existing RDF-graph. The annotation suits for the medication-information, since the medication is a speci c use-case, and is a temporary and contextual information element in the graph. Meaning, if the use-case changes, the annotation could be relevant for other observations and then be changed.
HTTP-Cal
DMRERSET--sSeervricveice FHIR-Store 1
FHIR-Store 2
Mapping-Service
Terminology
Service
From a system-architectural point of view, distributed services are present to ful ll the purpose of data collection, information retrieval, and refactoring of the collected information. So, a patient can use multiple FHIR-stores for storing his data (e.g., observation-resources, medication- administration resources). Another information source is the ontology for getting knowledge about a physiological e ect, but also the needed ontology-mapping is a distributed service. A centralized service, called 'Distributed Medical Rule Engine' (DMRE), takes care of building the resulting RDF-graph with the provided information. The trigger for this DMRE-service is a HTTP-REST-call.
The FHIR-Observation-store serves two purposes. Firstly, it is capable of storing patient's observation resources (vital signs, like heart rate, blood pressure). Secondly, it allows us to do queries to grab speci c information by formulating an exact query. For example, 'deliver all observations of a patient containing a heart rate coding'. The technical representation of the response is an FHIR-bundle that contains the results.
The FHIR-Medication-Administration- store is similar to the FHIR- observation - store, but for medication. A patient or medical personal can provide information about a medication administration. The FHIR-store allows asking queries for all medications of a patient. The query is doable since the medication administration has a reference to the patient, who took this medication. The response is an FHIR-bundle containing the medication-administrations. The medication-administration includes the applied drug, coding the information in SNOMED-CT (as de ned by HL7-FHIR).
For retrieving information available in another ontology, http://bioportal .bioontology .org o ers a REST-API to map from one ontology to another. In this case, from SNOMED-CT to NDF-RT. NDF-RT holds information about contraindication, physiological e ects, names of related products, which SNOMEDCT does not include. This mapping service is publicly available, located on a server on the internet. The result of the mapping is the ID of the corresponding ontology (here the NDF-RT-ID).
By using the resulting ID from the mapping service, an ontology query can be done. The ontology-query is accessible at a di erent service at another location. This service takes a SPARQL-query containing the NDF-RT-ID and processes the query over the NDF-RT-Ontology. The result is a list of the needed information, which then should be attached to the nal RDF-graph.
Building the RDF-graph containing medication annotations is a central task that triggers queries towards the FHIR-stores, the mapping-service, and the ontology-query-service. Once all the information is available centrally, the building of the graph is possible. Since it is a patient-centered application, the subject is the patient, with the observations as objects. As the medication is contextbased, an annotation called "a ectedByMedication" is attached to the observation, including the medication and the related physiological e ects. The representation of this RDF-graph is RDF/XML and returned to the user of the service.
A proof of concept implementation is setting up the services for querying FHIR-stores, mapping ontologies, asking SPARQL-queries towards an ontology, and building the RDF-graph.
The mainly used libraries are RDF4J, as well as HAPI-FHIR. Furthermore, the REST-API from bioportal.bioontology.org is used for the mapping of the ontologies.
The leading service, 'DMRE-Service', is triggered by an HTTP-GET-call
containing a patient-id. This generates further HTTP-calls to the di erent
FHIRStores to retrieve information about observations having special coding and
medications. For calculation, if a medication still a ects an observation, a
temporary table is created containing the medications' e ective-times and the dates
of the observations. The information about the half-life of a drug is accessible
in drugbank.ca and in an FHIR-resource called Medication-knowledge. So we
also calculate how much substance is still active. As mentioned in [
Building the RDF graph is relying on RDF4J, by using the RDF4J-modelinterface, the RDF4J-ValueFactory-interface, and the methods of the RDF4JIRI-interface. While iterating over the patient's observations, we create IRIs and statements to add information to the model. The same applies to the medicationlist, which is in the temporary table. While attaching the medication information, we do the ontology query for the physiological e ect. The RDF4J-class RIO (RDF I/O) takes the created model and writes it back to the client for further processing. 4
The used dataset for the FHIR observations and the FHIR medication administration resources is available on a public test server (http://hapi.fhir.org/). The ontology for the National Drug File - Reference Terminology, was a derivation of the original reference ontology, because of licensing issues. However, for the test samples, the ontology was complete. Since we evaluated the completeness of the solution in terms of retrieving the needed observations, and the medications, we created observations and medication-administrations for the PatientID 323827. By having just a reduced dataset, we were able to prove the correctness of the result. A second test with a random patient in the test server worked as expected, even if there was no medication in uence. However, the RDF-graph-creation for the patient-observation-relation was successful. The medication-administration data which exists in the test server had no suitable e ective-times, to match for any observations. 5
Concluding the information-collection from di erent FHIR-resources and medical ontologies is doable. As the universal data model for the di erent resources, we choose RDF. It is possible to formalize the knowledge and create relationships among di erent RDF-objects and RDF-subjects. Therefore it is achievable to create di erent views on a dataset by di erent use cases, to be prepared for an RDF-reasoner. Reconstruction of the FHIR-resources is needed because of FHIR's resource-oriented data model, but for the use case, a patient-centered view is needed. The ontologies from NDF-RT, provide the additional information to medication. This information helps, e.g., to know the physiological e ect of a medication on an observation. This medication information is then annotated to the graph.
The nal RDF-graph is now the source for a future reasoner, to make decisions. A next step is the integration of external information from sports activities to the RDF-graph because they can in uence the patient's vital signs in another way a medication does.