|
|
| (One intermediate revision by the same user not shown) |
| Line 15: |
Line 15: |
| | |date=2020-07-27 00:00:00 | | |date=2020-07-27 00:00:00 |
| | }} | | }} |
| − | =sessions=
| |
| − | {{Session
| |
| − | |title=Part 1: Rule Challenge @ RuleML+RR 2020
| |
| − | |volume={{PAGENAME}}
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | {{Session
| |
| − | |title=Part 2: Doctoral Consortium @ RuleML+RR 2020
| |
| − | |volume={{PAGENAME}}
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | {{Session
| |
| − | |title=Part 3: Industry Track @ RuleML+RR 2020
| |
| − | |volume={{PAGENAME}}
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | = papers =
| |
| − | == Paper 35 ==
| |
| − | {{Paper
| |
| − | |id={{PAGENAME}}/paper35
| |
| − | |title=Using PROVA-Rule Engine as Dispatching-Service for FHIR-Observation-Resources
| |
| − | |volume={{PAGENAME}}
| |
| − | |authors=Gerhard Kober, Adrian Paschke
| |
| − | |pdfUrl=http://ceur-ws.org/Vol-2644/paper35.pdf
| |
| − | |session=
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | === PDF ===
| |
| − | <pdf>http://ceur-ws.org/Vol-2644/paper35.pdf</pdf>
| |
| − | === TEI ===
| |
| − | <source lang='xml>
| |
| − | <?xml version="1.0" encoding="UTF-8"?>
| |
| − | <TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0"
| |
| − | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| |
| − | xsi:schemaLocation="http://www.tei-c.org/ns/1.0 /opt/grobid/grobid-home/schemas/xsd/Grobid.xsd"
| |
| − | xmlns:xlink="http://www.w3.org/1999/xlink">
| |
| − | <teiHeader xml:lang="en">
| |
| − | <fileDesc>
| |
| − | <titleStmt>
| |
| − | <title level="a" type="main">Using PROVA-Rule Engine as Dispatching-Service for FHIR-Observation-Resources</title>
| |
| − | </titleStmt>
| |
| − | <publicationStmt>
| |
| − | <publisher/>
| |
| − | <availability status="unknown"><licence/></availability>
| |
| − | </publicationStmt>
| |
| − | <sourceDesc>
| |
| − | <biblStruct>
| |
| − | <analytic>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">Gerhard</forename><surname>Kober</surname></persName>
| |
| − | <affiliation key="aff0">
| |
| − | <orgName type="institution">Tiani "Spirit" GmbH</orgName>
| |
| − | <address>
| |
| − | <settlement>Vienna</settlement>
| |
| − | <country key="AT">Austria</country>
| |
| − | </address>
| |
| − | </affiliation>
| |
| − | </author>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">Adrian</forename><surname>Paschke</surname></persName>
| |
| − | <affiliation key="aff1">
| |
| − | <orgName type="department">Fraunhofer FOKUS and Freie</orgName>
| |
| − | <orgName type="institution">Universitaet Berlin</orgName>
| |
| − | <address>
| |
| − | <settlement>Berlin</settlement>
| |
| − | <country key="DE">Germany</country>
| |
| − | </address>
| |
| − | </affiliation>
| |
| − | </author>
| |
| − | <title level="a" type="main">Using PROVA-Rule Engine as Dispatching-Service for FHIR-Observation-Resources</title>
| |
| − | </analytic>
| |
| − | <monogr>
| |
| − | <imprint>
| |
| − | <date/>
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − | </sourceDesc>
| |
| − | </fileDesc>
| |
| − | <encodingDesc>
| |
| − | <appInfo>
| |
| − | <application version="0.6.1" ident="GROBID" when="2021-01-08T11:56+0000">
| |
| − | <desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
| |
| − | <ref target="https://github.com/kermitt2/grobid"/>
| |
| − | </application>
| |
| − | </appInfo>
| |
| − | </encodingDesc>
| |
| − | <profileDesc>
| |
| − | <textClass>
| |
| − | <keywords>
| |
| − | <term>FHIR</term>
| |
| − | <term>PROVA</term>
| |
| − | <term>Rules</term>
| |
| − | </keywords>
| |
| − | </textClass>
| |
| − | <abstract>
| |
| − | <p>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 flexible 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.</p>
| |
| − | </abstract>
| |
| − | </profileDesc>
| |
| − | </teiHeader>
| |
| − | <text xml:lang="en">
| |
| − | <body>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>In a clinical-medical environment, vital signs from patients are important for diagnoses and the upcoming therapy <ref type="bibr" target="#b4">[5]</ref>. Usually, medical doctors are interested in two main things by evaluating the vital signs in clinical routine: first, if the vital signs are consistent over a timeline, and secondly, if there are outliers in medical values <ref type="bibr" target="#b8">[13]</ref>.</p><p>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' defined vital-sings), who then needs to set actions for the patient.</p><p>This paper analyzes the use of a rule-engine to fulfill 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.</p><p>The goal of this work is to set up a system architecture and a workflow 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.</p><p>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 notified to help this person. Another feature is to have these occurrences for later medical analysis of these non-normal medicinal values.</p><p>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.</p><p>FHIR (Fast Healthcare Interoperability Resources) is a standard created by HL7 (Health Level 7) [9]. FHIR defines resources, and they are defined by six layers to strap down the big healthcare domain <ref type="bibr" target="#b5">[8]</ref>. These layers are: 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 <ref type="bibr">[6]</ref>. For the FHIR-Observation, it is mandatory to have the following items in the object, which will then be sent to the FHIR-Store: the status and the code. The 'Observations-status' describes the status of result value and is used to track the individual results. The observation-status is coded and can just take defined values. The code describes the observed entity to understand the meaning of the observation. <ref type="bibr">[7]</ref>. Also, the value of the actual observation is useful (but not mandatory by definition). Other items in the observation can be included, but do not need to be. For the solution of the problem, the code and the observationvalue are important during processing to decide if the value is relevant for making decisions, and if so, in which way to use it.</p><p>As a rule engine for this dispatching-case PROVA [12] will be used. It supports the usage of event-driven reaction rules. Since there is a need in the overall process for high flexibility and the ability of the solution to express event-patterns and reactions, the complex event processing-lifecycle supported by Prova is helpful. Related to <ref type="bibr" target="#b3">[4]</ref> <ref type="bibr" target="#b1">[2]</ref> the CEP (complex event processing)-lifecycle contains:</p><formula xml:id="formula_0">-Event Production -Event Definition -Event Selection -Event Aggregation -Event Handling -Event Consumption.</formula><p>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 <ref type="bibr" target="#b0">[1]</ref>.</p><p>Other possible approaches besides the rule-based to be thought of are more restrictive and less flexible. 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 defined 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 flexible to build different 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 <ref type="bibr" target="#b2">[3]</ref>. These knowledge bases are encoded in the Arden Syntax, which is specialized for the needs of the language of so-called MLMs (Medical Logic Module). So the Arden-Syntax has a strong focus on medical information sharing and is useful for clinical processes. Going beyond the clinics and using FHIR, the Arden Syntax has no capabilities for obtaining clinical-medical decision support.</p></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">System design</head><p>The following section describes the planned system architecture, as well as the workflow. The following components are within the system architecture:</p><formula xml:id="formula_1">-FHIR-Client -Restful FHIR-Server -DMRE FHIR-Service • Prova-Receiver • Prova-Sender • FHIR-Client • ObservationParser -Knowledgebase • Extractor • Dispatcher -external FHIR-Server</formula><p>The following section describes the relations between the components having in mind the workflow as well.</p><p>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 FHIR-Observations to a so-called 'Distributed Medical Rule Engine' (DMRE) which contains a FHIR-Server. The DMRE is a container for different services, which need to be accessed during transaction time.</p><p>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.</p><p>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 define 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 workflow during execution-time.</p><p>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-FHIR-Service exists as an extra service because of the option to have another incoming path than the FHIR-Server (which intercepts the request). The external FHIR-Server 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 different decision (based on a different 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.</p><p>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.</p><p>Workflow: For the current use-case, the workflow 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. The workflow 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 workflow 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 filling 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 configuration of the rules and the extracted value, which FHIR-Server-Endpoint to use for the (final) submission. The 'dispatch'-rule finally 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.</p></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head>FHIR-Client</head></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head>FHIR-Restful</head><p>The general workflow during the execution process is for every observationtype and the attached values the same, but the specific details on 'what' goal need to be achieved can be changed due to the needs of the use case.</p></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Implementation</head><p>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-FHIR-Library <ref type="bibr" target="#b6">[10]</ref> for essential FHIR services.</p><p>For testing a sample use case, a reduced example from the HL7-FHIR-Resource page of samples is used. This one is then sent via HTTP-Post to the FHIR-Endpoint in the DMRE.</p><p>The HAPI-FHIR-Library provides a servlet, which allows us to set up an FHIR-Server in general, but without having specific resources implemented. This allows us to build up our own needs in the implementation, by creating for example a specific '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. 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 defined ordering of parameters <ref type="bibr" target="#b7">[11]</ref> that is used for the decision if it is an extraction-task or a dispatching-task. The parameters are the following ones <ref type="bibr" target="#b7">[11]</ref>:</p><p>-XID -conversion-ID of the message -Protocol -Name of the message passing protocol -Destination -Performative -the message type broadly characterizing the meaning of the message -Payload For this task, the 'Destination' is used -either 'FHIR' for the data-extraction and further ongoing submission to the second rule-base or 'DISPATCHER' for executing the submission to the next FHIR-Endpoint.</p><p>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 finally.</p><p>The dispatching-rule has information about the decision to submit to a different endpoint, and it also holds the information on the endpoint.</p><p>In Listening 1.2, a reaction-routing functionality is used to find 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 FHIR-Observation to the meant endpoint, by using an implementation of an FHIR-Client. 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.</p><p>The code is available on Github https://github.com/gkober/DMRE. As a side note: in the code are two options implemented: first, using "hardcoded" observation-types (by configuration), and secondly, the opportunity for the ruleengine is available. The usage of the different options can be done by configuration.</p></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Results and Discussion</head><p>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 flexible, because of the rules which take control of the decision-points.</p><p>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 definition, correct, but for a production system, it is probably not relevant to take care of this topic.</p><p>Finally, the architecture and the decision to use the rule-engine Prova turned out to be a reasonable solution providing the required flexibility and adaptability as well as extendability of the architecture. This helps to improve the overall solution of the 'distributed medical rule engine'.</p></div>
| |
| − | <div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Future Work</head><p>Based on this work, further topics need to be addressed. One is to extend the solution for other FHIR-Resources, which are valuable for different 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 field that needs to be addressed.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Fig. 1 .</head><label>1</label><figDesc>Systemarchitecture</figDesc></figure>
| |
| − | <figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Fig. 2 .</head><label>2</label><figDesc>Sequence FHIR-Client, Interception and final submission</figDesc></figure>
| |
| − | <figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>Listing 1 . 1 .</head><label>11</label><figDesc>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 , { o b s e r v a t i o n −>O b s e r v a t i o n } ) , 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 , { g l u c o s e −>O b s e r v a t i o n } ) .</figDesc></figure>
| |
| − | <figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_4"><head>Listing 1 . 2 .</head><label>12</label><figDesc>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 , { val ue −>O b s e r v a t i o n } ) , routeToFHIR ( Agent , O b s e r v a t i o n ) , sendMsg ( "XID3" , o s g i , "DISPATCHER" , inform , { endpoint −>Agent } ) .</figDesc></figure>
| |
| − | <figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_5"><head></head><label></label><figDesc>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 ) :− Observation >7. normal ( O b s e r v a t i o n ) :− Observation <=7.</figDesc></figure>
| |
| − | <figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head>Server DMREFhirServer Observation- Parser Knowledgebase (Extractor) Knowledgebase (Dispatcher) External FHIR- Server (storage)</head><label></label><figDesc></figDesc><table><row><cell>result</cell><cell>execution</cell><cell cols="2">Return</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>Observation</cell><cell>Send</cell></row><row><cell></cell><cell cols="2">result</cell><cell>execution</cell><cell>Return</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>Observation</cell><cell>Forward</cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell>Return execution result</cell><cell>Forward Observation to desired endpoint</cell><cell>Return FHIR-Endpoint</cell><cell>Choose FHIR-Endpoint to submit</cell><cell>Check if value is normal or not Send extracted value</cell><cell>Return extracted value</cell><cell>Extract needed Value</cell><cell>Save Observation temporary</cell><cell>Send Back observation and value to extract</cell><cell>Check for needed Value ProvaService.send ("extractor", Observation)</cell></row></table><note></note></figure>
| |
| − | </body>
| |
| − | <back>
| |
| − | <div type="references">
| |
| − |
| |
| − | <listBibl>
| |
| − |
| |
| − | <biblStruct xml:id="b0">
| |
| − | <monogr>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">A</forename><surname>Paschke</surname></persName>
| |
| − | </author>
| |
| − | <ptr target="https://pdfs.semanticscholar.org/d8f9/e961df8c4103a2d698f962d3460305d43564.pdf" />
| |
| − | <title level="m">Semantic Web Rules</title>
| |
| − | <imprint>
| |
| − | <biblScope unit="page" from="2020" to="2025" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b1">
| |
| − | <monogr>
| |
| − | <title level="m" type="main">The Reaction RuleML Classification of the Event/Action/State Processing and Reasoning Space</title>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">A</forename><surname>Paschke</surname></persName>
| |
| − | </author>
| |
| − | <ptr target="https://arxiv.org/ftp/cs/papers/0611/0611047.pdf" />
| |
| − | <imprint>
| |
| − | <date type="published" when="2006" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b2">
| |
| − | <analytic>
| |
| − | <title level="a" type="main">Health Level Seven Arden Syntax for Medical Logic Systems</title>
| |
| − | <idno>2.10</idno>
| |
| − | <ptr target="https://www.hl7.org/implement/standards/productbrief.cfm?productid=372" />
| |
| − | </analytic>
| |
| − | <monogr>
| |
| − | <title level="j">Arden Syntax</title>
| |
| − | <imprint>
| |
| − | <biblScope unit="page" from="2020" to="2025" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b3">
| |
| − | <monogr>
| |
| − | <ptr target="https://de.slideshare.net/swadpasc/paschke-rule-ml2014keynote" />
| |
| − | <title level="m">Semantic CEP with Reaction RuleML</title>
| |
| − | <imprint>
| |
| − | <biblScope unit="page" from="2020" to="2025" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b4">
| |
| − | <analytic>
| |
| − | <title level="a" type="main">The Importance of Vital Signs in the Triage of Injured Patients</title>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">E</forename><surname>Chalari</surname></persName>
| |
| − | </author>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">G</forename><surname>Intas</surname></persName>
| |
| − | </author>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">S</forename><forename type="middle">P</forename></persName>
| |
| − | </author>
| |
| − | <idno type="DOI">10.1097/CNQ.0b013e318255d6b3</idno>
| |
| − | <ptr target="https://doi.org/doi:10.1097/CNQ.0b013e318255d6b3" />
| |
| − | </analytic>
| |
| − | <monogr>
| |
| − | <title level="j">Critical Care Nursing Quarterly</title>
| |
| − | <imprint>
| |
| − | <biblScope unit="volume">35</biblScope>
| |
| − | <biblScope unit="page" from="292" to="298" />
| |
| − | <date type="published" when="2012" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b5">
| |
| − | <monogr>
| |
| − | <ptr target="https://www.hl7.org/fhir/overview-arch.html" />
| |
| − | <title level="m">HL7 FHIR: Architect's Introduction</title>
| |
| − | <imprint>
| |
| − | <biblScope unit="page" from="2020" to="2025" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b6">
| |
| − | <monogr>
| |
| − | <title/>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">Fhir</forename><surname>Hapi Fhir -The Open Source</surname></persName>
| |
| − | </author>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><surname>Api</surname></persName>
| |
| − | </author>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><surname>Java</surname></persName>
| |
| − | </author>
| |
| − | <ptr target="https://hapifhir.io" />
| |
| − | <imprint>
| |
| − | <biblScope unit="page" from="2020" to="2025" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b7">
| |
| − | <monogr>
| |
| − | <title level="m" type="main">Prova Rule Language Version 3.0, User's guide</title>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">A</forename><surname>Kozlenkov</surname></persName>
| |
| − | </author>
| |
| − | <imprint>
| |
| − | <date type="published" when="2010-05" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | </biblStruct>
| |
| − |
| |
| − | <biblStruct xml:id="b8">
| |
| − | <analytic>
| |
| − | <title level="a" type="main">Evidence based decisions in nursing and their effect on quality of care</title>
| |
| − | <author>
| |
| − | <persName xmlns="http://www.tei-c.org/ns/1.0"><forename type="first">M</forename><surname>Versloot</surname></persName>
| |
| − | </author>
| |
| − | <ptr target="https://hdl.handle.net/11245/1.385728" />
| |
| − | </analytic>
| |
| − | <monogr>
| |
| − | <title level="m">Faculty of Medicine</title>
| |
| − | <imprint>
| |
| − | <publisher>AMC-UvA</publisher>
| |
| − | <date type="published" when="2012" />
| |
| − | </imprint>
| |
| − | </monogr>
| |
| − | <note type="report_type">Ph.D. thesis</note>
| |
| − | </biblStruct>
| |
| − |
| |
| − | </listBibl>
| |
| − | </div>
| |
| − | </back>
| |
| − | </text>
| |
| − | </TEI>
| |
| − |
| |
| − | </source>
| |
| − | {{Paper
| |
| − | |id={{PAGENAME}}/paper44
| |
| − | |title=One-Shot Rule Learning for Challenging Character Recognition
| |
| − | |volume={{PAGENAME}}
| |
| − | |authors=Dany Varghese, Alireza Tamaddoni-Nezhad
| |
| − | |pdfUrl=http://ceur-ws.org/Vol-2644/paper44.pdf
| |
| − | |session=
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | <pdf>http://ceur-ws.org/Vol-2644/paper44.pdf</pdf>
| |
| − | {{Paper
| |
| − | |id={{PAGENAME}}/paper36
| |
| − | |title=Action Rules: Counterfactual Explanations in Python (winner of the 14th Rule Challenge 2020 competition)
| |
| − | |volume={{PAGENAME}}
| |
| − | |authors=Lukas Sykora, Tomas Kliegr
| |
| − | |pdfUrl=http://ceur-ws.org/Vol-2644/paper36.pdf
| |
| − | |session=
| |
| − | |storemode=subobject
| |
| − | }}
| |
| − | <pdf>http://ceur-ws.org/Vol-2644/paper36.pdf</pdf>
| |
edit