Clinical medical data can be accessed as HL7 Fast-HealthCare-Interoperability-Resources (FHIR). These resources can be used as the basis for further processing in semantic rule engines. To access them using Semantic Web technologies they need to be transformed to RDF so that they can be queried with SPARQL. This paper proposes an approach to convert FHIR resources to RDF. The implementation provides an RDF interface for accessing FHIR stores with SPARQL using the Apache Jena library.
The medical HL7-standard Fast Healthcare Interoperability Resources (FHIR)
provides the option to represent FHIR resources as RDF graph [
Usually FHIR based systems are used for providing interoperability, and do not provide RDF interfaces. Such an interface is needed to perform e.g. SPARQL queries. Another problem is that FHIR resources are often stored highly distributed.
These issues need to be addressed before further processing the results in semantic rule engines. The challenge is to combine the query outcomes and parse the complete RDF model.
The key component contributed in this paper is a FHIR-to-RDF converter, using
existing libraries, combining these to ful ll the needed requirements. By now the
limitation is that the client needs to know which type of resource is expected
in addition to the query URL. Since the query is not limited, all results from a
FIHR store are returned.
{ Resources: resources are collections of information-models, de ning data
elements, constraints and relations between these business-objects
{ APIs: APIs are collections of well-de ned Interfaces to describe the
interoperability between applications
FHIR is describing the data structure, the data ow between systems, and the
links between di erent resources. For data exchange FHIR supports the following
interoperability paradigms: RESTful API, Messaging, Documents and Services
[
There are more than hundred resources de ned - e.g. Patient, Observation, Medication and FHIR allows the extension and creation of own resources. In this paper the term "FHIR store" is mentioned. This describes the storage container for di erent FHIR resources, providing an interface for REST calls to insert, update and query FHIR resources.
In [
The system-architecture for the proof of concept implementation consists of three components (see Fig.1): 1. The client, calling the FHIR-to-RDF converter in order to provide the URL to the FHIR store itself, the FHIR version of the FHIR store and the type of FHIR resource, that is expected to be returned for further processing on the client-side. 2. The FHIR-to-RDF converter: This is a central component in our solution, since it is dispatching the HTTP calls to di erent servers, and transforming the incoming FHIR bundles to RDF. 3. The FHIR store: this is the place where all the FHIR resources (e.g patient, observations, medications) are persisted.
The proposed system architecture is meant to be a centralized one, because of the following advantages: { the result of a speci c query is always complete (for further processing) { the approach (implementation) is applicable to every FHIR store, even if it does not provide an RDF interface { less re-querying is needed: doing a re-query might be necessary, if the client needs more information than provided (this cannot happen if the complete information is available on the client-side) A disadvantage of the centralized approach might be the processing of big data and the need of data replication in the execution environment if the data cannot be managed in memory.
t n e li C getRDF(Observation) provideRDF - r t-o -F tree IRH RD vno F C
e r o t S R I H F The concrete Implementation The implementation is done using Java, with the support of the HAPI-FHIR library and the Apache-Jena library. For the proofof-concept-implementation the client is a method of the FHIR-to-RDF converter. The client passes the URL, the FHIR version and the FHIR resource-type of the FHIR store to the connector method of the FHIR-to-RDF converter.
The connector method is able to call an FHIR endpoint using HTTP, in order to do queries for a speci c sort of FHIR resource. The HAPI-FHIR library provides a RestfulGenericClient in order to connect to di erent Servers. This library also takes care on di erent versions of the FHIR standard. There are options for Dstu2, Dstu3, R4.
Next is the search process in the FHIR store: The HAPI-FHIR library also provides methods for searching resources. In this implementation the FHIR resource-types Observation and Patient are taken into account. The result of such an invocation is a FHIR bundle. This bundle contains all FHIR resources for a speci c type, returned from the server. When we have this result set we need to create out of this a RDF Model. There is also an RDFParser included in the HAPI-FHIR library. Before translating the FHIR resource to RDF a valid FHIR resource (containing all the information) is needed. Shown in listening 1.1 there is a reduced sample of such a FHIR resource. {"resourceType": "Observation", "category": [..Vital Signs..], "subject": { "reference": "Patient/PatientID1" }, "effectiveDateTime": "2019-03-31T08:00:00.000", "component": [{ "code": "coding": [... Systolic blood pressure ...], "valueQuantity": { "value": 100, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg ]"}},{ "code": "coding": [... Diastolic blood pressure ...], "valueQuantity": { "value": 80, "unit": "mmHg",
"system": "http://unitsofmeasure.org", "code": "mm[Hg]"} }],"id": "3162fab0-9569-48a1-bec3-1ebaeef1165f"}
This reduced sample contains the resource type, to which patient this observation belongs to, and the observation itself (in our example the systolic and diastolic blood-pressure). From the FHIR bundle returned by the HAPI-FHIR library (i.e. the Java-object) the resource items are iteratively extracted in order to have a list of resources.
The convertFhirToRdf -method takes as input the resource list created before and returns an Apache Jena RDF model. The Apache Jena library is able to create a new model, which is used as a skeleton for the new parsed FHIR resources. Adding resources is done by iterating over the complete list, writing it to a stream, which itself is used as input parameter for the Apache Jena model read method. Listening 1.2 shows the transformation from the FHIR bundle to the RDF model.
public Model convertFhirToRdf(List<Resource> res) throws
IOException { RdfParser parser = new RdfParser(); ByteArrayOutputStream bOut = new ByteArrayOutputStream(); model = ModelFactory.createDefaultModel(); for (Resource elem : res) {
bOut.write(parser.composeString(elem).toString().getBytes()); } model.read(new ByteArrayInputStream(bOutput.toByteArray()),null ,"TTL"); return model; }
4
Performance is a critical point in this solution. There are two steps which are time consuming: The HTTP call to the FHIR store including the response, and the conversion from FHIR to RDF. The rst step is depending on the network connection and the overall performance of the FHIR store. In a test-setup with a public FHIR Server ("http://test.fhir.org") this connection and retrieval of the result took in average 6.5 seconds.
Since we used a public test server, the network-delay is pretty high. For simulation of potentially high amounts of FHIR observations, a single result of the FHIR store was copied multiple times and then transformed to RDF. As shown in gure 2, the conversion for 5000 observations to RDF takes about 2.5 seconds - for an amount of 25000 observations 11.4 seconds are needed on a local machine.
When debugging the duration, it was found that a over-all conversion for 76 observations takes about 500ms. This is because of the initialization time of the Apache Jena class "RDF model" which takes approximately 300ms and the HAPI-Class "RdfParser" which takes about 100ms. The performance is not getting worse if there are more than 10 times more observations in the result, which are needed to be converted, because the initialization of the Apache Jena class and HAPI-RdfParser is just done once in the routine. As seen in gure 2 there is a linear increase of the needed time for conversion.
ConversionTimes snauonD m iitr 12500 10000 7500 5000 2500 0 5000 10000 15000
Number of Samples 20000 25000 The proposed solution has some issues, taking into account that performance might be a bottleneck. The queries on the FHIR store should be specialized to goal in order to get exactly these results back, which are actually needed for further processing. A "query-all" approach is too expensive for a high amount of results. Furthermore, the translation to the Apache-Jena model might be ine ective for a high load of data. 6
This paper has proposed and implemented a FHIR-to-RDF converter, which can be used to convert existing FHIR resources from a FHIR store into RDF. This is done in three steps: rst the FHIR resources is fetched via REST, second the FHIR bundle is parsed to an input stream and third an Apache Jena model is provided by reading the input stream into the newly created model. Our converter provides the basis for SPARQL queries on FHIR resources without the need of a FHIR store with an RDF interface. The centralized approach of our conversion tool provides the advantage that not all information is needed in one place.