In a clinical medical environment, vital signs of patients are crucial information. In order to have the right information at the right time available, they need to be evaluated during the storage-process and then be submitted to special store-containers or to alerting-servers. To achieve the goal of observation-information-based dispatching, a rule engine is used to be highly exible in the evaluation of health parameters and limits. The assumption is that such a declarative rule-based service is easier to maintain, and can also work in a distributed way. The distribution of the rule-engine is in the setting of a clinic-group (where many hospitals work together) fundamental to allow each hospital to work independently of the others.
In a clinical-medical environment, vital signs from patients are important for
diagnoses and the upcoming therapy [
So the issue is to detect 'abnormal' values and decide dynamically where to store patient's data, to have it available for the physician (besides the as 'normal' de ned vital-sings), who then needs to set actions for the patient.
This paper analyzes the use of a rule-engine to ful ll the needs of a future 'distributed medical rule-engine'. Furthermore, the values of the medical data, which exist in the form of FHIR-resources (Fast Healthcare Interoperability Resources) needs to be extracted, and the decisions need to be taken during the storage-process.
The goal of this work is to set up a system architecture and a work ow that allows us to receive FHIR-Observation-resources, which are meant for storage, extract the needed values of a particular type of information and decide on the retrieved information which storage-endpoint to use.
A use-case for this can be found for people who have diabetes, where the blood glucose level is highly relevant. So if the level falls under a certain level, a doctor (or another medical person) should get noti ed to help this person. Another feature is to have these occurrences for later medical analysis of these non-normal medicinal values.
A solution for the problem is needed to improve patient care, because of clear, relevant information and gathering information for answering medical-clinical research questions, based on vital signs.
FHIR (Fast Healthcare Interoperability Resources) is a standard created by HL7
(Health Level 7) [
In this work, the clinical resources from layer three are used. To be more precise,
the observation-resource is the target-resource. For the support of diagnosis or
patient monitoring, the observations-resource is a central element in healthcare
[
As a rule engine for this dispatching-case PROVA [
These events will be processed during the actual execution. Prova provides the
ability to use a declarative programming paradigm in conjunction with an
objectoriented programming paradigm. There is a separation on the program-logic (the
declarative part), the data-access, and optional external procedural
computations [
Other possible approaches besides the rule-based to be thought of are more
restrictive and less exible. For a very special use-case, a solution could be
implemented 'hardcoded' by doing all the needed calculations and comparisons in
the code. Still, if someone likes to change comparison-values or change the
usecase, it takes a lot of changes in the program logic. Furthermore, if a second
or a third factor for a decision needs to be taken into account, the 'hardcoded'
solution will become complicated and hard to maintain. Therefore this is not
the preferred solution. When taking into account that not only FHIR-resources
or data structures de ned in the medical domain are relevant for making
decisions, a more generic solution is needed. It has to be based on standards and to
be generic and exible to build di erent options for needed decision points. For
example, there is HL7-Arden-Syntax, which is used for representing procedural
clinical knowledge in order to share health knowledge bases [
The following section describes the planned system architecture, as well as the work ow.
Systemarchitecture
Prova-Receiver Prova-Sender
FHIR-Client ObservationParser
(e.g. Storage endpoint, or other DMRE)
Extractor
Dispatcher
The following components are within the system architecture: { FHIR-Client { Restful FHIR-Server { DMRE FHIR-Service
Prova-Receiver Prova-Sender FHIR-Client
ObservationParser { Knowledgebase
Extractor
Dispatcher { external FHIR-Server The following section describes the relations between the components having in mind the work ow as well.
The system architecture: From an architectural point of view, the solution is based on FHIR as a state-of-the-art standard for sending and receiving medical data. Therefore, any (external) FHIR-Client is needed to send the FHIRObservations to a so-called 'Distributed Medical Rule Engine' (DMRE) which contains a FHIR-Server. The DMRE is a container for di erent services, which need to be accessed during transaction time.
The FHIR-Client is responsible for the creation of conformant JSON-objects, containing the appropriate values for the designated resource. The FHIR-Server provides a RESTful-service to receive FHIR-resources (e.g., Patient-resources, Observation-resources) by using HTTP. The server has to be able to accept HTTP-calls for inserting, updating, and deleting resources.
The DMRE-FHIR-Service is a service that provides the interfaces for the PROVA-rule-engine, as well as an FHIR-Client and an Observation parser. The rule-engine interacts with the Knowledge base. The knowledgebase contains the rules. There are rules which de ne which value needs to be extracted for further processing, and also rules for the dispatching of the FHIR-resources. These rules are providing the 'logic' in the work ow during execution-time.
The DMRE-FHIR-Service can send incoming requests from the FHIR-Server to the extractor-rule. Secondly, the DMRE-FHIR-Service can receive incoming requests from the Rules for upcoming processing. Here is meant to either get the information of extraction (which value to extract from the FHIR-Observation), or the dispatch information (where to process the FHIR-Observation to). For the extraction, the Observation-parser is needed, to grab the relevant information (requested code and value), if it exists in the observation. This DMRE-FHIRService exists as an extra service because of the option to have another incoming path than the FHIR-Server (which intercepts the request). The external FHIRServer is the chosen endpoint by the rule-engine, executed by the FHIR-Client in the DMRE-FHIR-Service. This endpoint could be the goal (target) server, which is responsible for the persistence of the observation resource. It could be another DMRE-RESTful-FHIR-Server-instance, which proceeds other rules and takes a di erent decision (based on a di erent set of rules). That means it is possible to have the integrated rule-engine used in a distributed way, and no central component is needed. Still, it could be on the edge of a wide distributed inter-operable health system.
The system architecture is designed to intercept the incoming FHIR-Observationrequest for the information extraction and make decisions based on the rules about the FHIR endpoint.
Work ow: For the current use-case, the work ow during the transaction process in this architecture is based on the fact that an observation-type (e.g. a heart-rate or glucose-level) and a decision for 'normal' or 'not normal' is needed. e x R rse ecu teu u lt ito rn n e x R rse ecu teu u lt ito rn n
F o rw R
e a t r u d r
n O b F s H R re IR e v t a E u t n r io d n n p e t o x o i e n c d t u e t s io ir n e
d r e e s n u d lt p o i n t
C h o o s e F H I R E n d p o i n t t o s u b m it
S e n d e x t r a c t e d v a l u e C h e c k if v a l u e i s n o a l o r n o t r m
R
E e t u r n e x t r a c t e d v a l u e x t r a c t n e e d e d V a l u e
S a v e O b s e r v a t i o n t e m p o r a r y
S e n d B a c k o b s e r v a t i o n a n d v a l u e t o e x t r a c t
O b se S r e v n a d t i o n O b F s o e r r w v a a it rd o n C h e c k V a l u e F H I R C il e n t D M R E F h ir S e r v e r O b raP res s v re itao n K n (E ow trx le a d c g )tro aeb s e K (D no is w p le a d tc g h e e b )r sa e revS txE re re n ( ts la o F r ag IHR )e
Fig. 2. Sequence FHIR-Client, Interception and nal submission
The work ow starts by having an FHIR-Client submitting an FHIR-Observation to the DMRE-FHIR-Restful-Server. The DMRE-FHIR-Restful-Server intercepts the request by calling the DMRE-FHIR-Service and forwarding the observation there. This DMRE-FHIR-Service is the core component in the work ow since it coordinates requests and takes care of responding to the initial requestor. The DMRE-FHIR-Service forwards the observation to the 'extractor'-Rulebase. This extractor is aware of which value needs to be extracted to have the right information for the upcoming dispatching. The extractor-rule returns than the 'to-be-extracted' value and observation. This task of lling the needed value and an FHIR-Observation can also be done by any external component. The DMRE-FHIR-Service keeps the current observation to proceed with the following parsing and extraction. The observation-parser simply returns the extracted value, which will then be submitted to the 'dispatch'-rule. This rule decides (e.g., if a value is a normal value or a not-normal value), based on the con guration of the rules and the extracted value, which FHIR-Server-Endpoint to use for the ( nal) submission. The 'dispatch'-rule nally returns the endpoint to the DMRE-FHIR-Service, which then acts as an FHIR-Client and submits the initial observation to the decided endpoint. The endpoint returns an execution-result, which will be processed back through the entire processing-chain, to have the initial FHIR-Client informed about successful storage.
The general work ow during the execution process is for every observationtype and the attached values the same, but the speci c details on 'what' goal need to be achieved can be changed due to the needs of the use case. 3
The implementation of the Distributed Medical Rule Engine (DMRE) is done in
Java by including Prova-libraries for the rule-engine-parts and the
HAPI-FHIRLibrary [
For testing a sample use case, a reduced example from the HL7-FHIRResource page of samples is used. This one is then sent via HTTP-Post to the FHIR-Endpoint in the DMRE.
The HAPI-FHIR-Library provides a servlet, which allows us to set up an FHIR-Server in general, but without having speci c resources implemented. This allows us to build up our own needs in the implementation, by creating for example a speci c 'RestfulObservationResourceProvider', which then can call the DMRE-FHIR-Service-code. The DMRE-FHIR-Service acts as a client for sending the received JSON-Object to the rule-engine. The call is submitted to the extractor. A sample listening for the extractor is in Listening 1.1.
Listing 1.1. Sample Extractor.prova : e v a l ( e x t r a c t o r ( ) ) . e x t r a c t o r ( ) : rcvMult (XID , P r o t o c o l , From , inform ,
f o b s e r v a t i o n >O b s e r v a t i o n g ) , routeTo2 ( O b s e r v a t i o n ) . routeTo2 ( O b s e r v a t i o n ) : sendMsg ( " XIDExtractor " , o s g i , "FHIR" , inform ,
f g l u c o s e >O b s e r v a t i o n g ) .
The knowledgebase (extractor-rule) has the information WHAT to extract. It receives the observation as a string, and 'routeTo2' (which means send it back to the Java-process - 'Step 2') also has the information which observation-type to take care of. In the sample, it takes care of the glucose-coding.
The java-code contains a Prova-Callback, to receive calls from the rule-engine.
Prova has a de ned ordering of parameters [
Once the Prova-callback is hit by the Destination 'FHIR', the Java-code tries to parse the FHIR-Observation, extract the value from there, and return it, to then put this information in a further call to the Dispatcher-rule, to take the decision where to send the FHIR-Observation-Resource nally.
The dispatching-rule has information about the decision to submit to a different endpoint, and it also holds the information on the endpoint.
In Listening 1.2, a reaction-routing functionality is used to nd the correct endpoint if the value of the observation is normal or another if it is abnormal. Once found out about the status of the value, the "routeToFHIR" either takes the event processing agent for FHIR-Endpoint A (http://hapi.fhir.org/baseR4) or B (http://hapi2.fhir.org/baseR4). This information is then sent back to the Prova-Callback with the Prova-Destination 'DISPATCH', to submit the FHIRObservation to the meant endpoint, by using an implementation of an FHIRClient.
Listing 1.2. Sample Dispatcher.prova : e v a l ( d i s p a t c h e r ( ) ) . d i s p a t c h e r ( ) : rcvMult (XID , P r o t o c o l , From , inform ,
f v a l u e >O b s e r v a t i o n g ) , routeToFHIR ( Agent , O b s e r v a t i o n ) , sendMsg ( "XID3" , o s g i , "DISPATCHER" , inform ,
f e n d p o i n t >Agent g ) . routeToFHIR ( " h t t p : / / h a p i . f h i r . o r g / baseR4 " , O b s e r v a t i o n ) : abnormal ( O b s e r v a t i o n ) . routeToFHIR ( " h t t p : / / h a p i 2 . f h i r . o r g / baseR4 " , O b s e r v a t i o n ) : normal ( O b s e r v a t i o n ) . abnormal ( O b s e r v a t i o n ) :
O b s e r v a t i o n >7. normal ( O b s e r v a t i o n ) :
O b s e r v a t i o n <=7.
After processing the information to the next FHIR-Server, the response from the server is then returned to the client (for successful and also for not successful submissions). This is achieved by the HAPI-FHIR-Method 'MethodOutcome'. Important to say, that the initial JSON-Object is not changed in terms of content. The transformations are done for the necessary extraction to allow the decision based on values.
The code is available on Github https://github.com/gkober/DMRE. As a side note: in the code are two options implemented: rst, using "hardcoded" observation-types (by con guration), and secondly, the opportunity for the ruleengine is available. The usage of the di erent options can be done by con guration. 4
The presented work shows the ability to achieve rule-based dispatching to different FHIR-Servers for obtaining patient's observations, which are critical for patient care. The solution is highly exible, because of the rules which take control of the decision-points.
During the evaluation of the implementation, simple observations containing e.g., glucose-values or heart-rate values, the solution works appropriately by the extraction and the dispatching. There is a known issue in the implementation, which takes care of 'combined observations'. This means if an observation has two or more codes and values (e.g., blood pressure). The implementation is susceptible to the correctness of the FHIR-Observation. For example, an observation without a value returns in error. Such an observation is, by de nition, correct, but for a production system, it is probably not relevant to take care of this topic.
Finally, the architecture and the decision to use the rule-engine Prova turned out to be a reasonable solution providing the required exibility and adaptability as well as extendability of the architecture. This helps to improve the overall solution of the 'distributed medical rule engine'. Based on this work, further topics need to be addressed. One is to extend the solution for other FHIR-Resources, which are valuable for di erent types of information dispatching and extraction. In the rules, the user mentions the "type" of information which needs to be extracted - therefore, information retrieval from a terminology-service needs to found. Also, the dispatching of patient-basis and combinations is a eld that needs to be addressed.