1. Demo HomePage: AI Automation at the Edge

2. Use case presentation

3. Live Demo Example

1. Operations

   1. Ansible for automated and repeatable deployment of Application Services to OpenShift

   2. Deployment of Red Hat Application Services products via Operator Lifecycle Manager

2. Events in Motion

   1. Use of Red Hat AMQ Streams

   2. Use of Debezium for Change Data Capture on HAPI FHIR database

   3. Use of both Binary and Structured Cloud Events

   4. Visibility of events via KafDrop

   5. Raw FHIR related Server Sent Events streamed to Angular UI

3. Process Automation

   1. RH-PAM embedded in SpringBoot as process automation engine

   2. BPMN models with process variables of type FHIR R4

   3. User Task centric process model with Task lifecycle driven by clients via KIE-Server API

   4. Angular based simple Task Inbox web app

   5. KIE-Server APIs extended with custom endpoints that allow for (un)marshalling of HAPI FHIR R4 resources

   6. jBPM Executor Service for asyncroneous tasks

   7. Dashbuilder for process and task related monitoring and KPIs

4. Web Security

   Please see OIDC Enabled Workflow Apps for details.

   1. Use of OIDC Authorization Code Flow protocol between RH-SSO and Angular web app to obtain JWT based access token

   2. Access token includes users roles so as to facilitate UserGroupCallback functionality in RH-PAM

   3. KIE-Server APIs of RH-PAM secured via RH-SSO as Bearer-Token endpoints

5. Polyglot Frameworks

   1. Quarkus

   2. SpringBoot

   3. JBoss EAP

   4. Python

   5. KNative Serverless functions

   6. Angular

6. Machine Learning

   1. Machine Learning algorithm to determine probability of Sepsis

1. In the Openshift console, navigate to the routes in the user1-sepsisdetection namespace

   

   1. Click the URL of the sepsisdetection-ui route.

      

2. Authenticate in using credentials of: pamAdmin / pam

3. Click the Reset Demo button:

   

4. After a few seconds, there should be an active business process:

   

5. Click the Log out button at the top right corner to log out as an Administrator.

1. Log back into the Sepsis Detection UI as a doctor.

   Use credentials of: eve / pam.

2. Click Show/Hide Workflow:

   

   Notice the timer on the Primary Doctor Evaluates Risk task. For the purpose of the demo, this timer is set to 1 minute. If not administered within 1 minute of creation, the workflow will automatically route to the On Call Doctor Evaluates Risk task.

3. Click the My Tasks tab:

   

4. On any of the tasks, click the Open button and decide on an appropriate course of action.

   

   1. Select one of the options from the Risk Evaluation Result drop-down.

   2. Click Submit.

5. Click the Log out button at the top right corner to log out as a doctor.

1. Log back into the Sepsis Detection UI as a provider.

   Use credentials of: bob / pam.

2. Similar to what you already did as a simualated doctor, manage the lifecycle of any tasks assigned to a provider.

Red Hat SSO is used as the OpenID Connect provider of access tokens needed by other demo components for authentication and authorization.

For the purpose of the demo, the RH-SSO consists a single SSO realm configured with an SSO client and multiple users and roles to facilitate the use case.

The demo consists of a HAPI FHIR JPA server .

This server maintains the state of all FHIR resources involved in the sepsis detection use case.

The HAPI FHIR server is backed by a PostgreSQL database.

The architecture of the demo is primarily event driven.

As such, the demo makes use of Red Hat’s AMQ Streams and Debezium technologies.

For monitoring of kafka topcs in AMQ Streams, the demo provides an instance of Kafdrop

Kafdrop allows for instrospection of messages in the kafka topics.

This service consists of the RH-PAM process_engine embedded in SpringBoot.

1. This service consumes messages from Red Hat AMQ Streams

   In particular, it consumes change events from the PostgreSQL database of the HAPI FHIR server.

   ie: When a new FHIR Patient resource is posted to the HAPI FHIR REST API, a record is added to the HAPI FHIR PostgreSQL database. Subsequently, a change event that captures this database record is sent to an AMQ Streams/Kafka topic.

2. This service also exposes the following RESTful APIs:

   1. Standard RH-PAM KIE-Server REST APIs

      

   2. FHIR Enabled REST APIs:

      Augments the RH-PAM KIE-Server with additional APIs that allow for handling FHIR related process and task variables

For monitoring of business processes and user tasks the demo provides an instance of RH-PAM’s dashbuilder technology.

The demo provides a user interface written in AngularJS .

This UI allows role-based-access-control to various features based on the roles in the SSO access token of an authenticated user.

1. sepsisdetection parent process

   

2. highmediummitigation Subprocess:

   

1. An external client POSTs a FHIR R4 bundle (with a Patient, Location and multiple Observation resources ) to the RESTful API of the HAPI FHIR JPA server.

2. HAPI FHIR JPA Server persists (using Hiberate) to its PostgreSQL database. FHIR resources are stored as gzip blobs in the following table of the HAPI FHIR database schema: public.hfj_res_ver .

3. Debezium detects the additional records to the public.hfj_res_ver table and puts them in motion by sending the raw GZIP blobs to a kafka topic: fhir.public.hfj_res_ver

4. Messages in the fhir.public.hfj_res_ver topic can now be viewed via monitoring tools such as KafDrop. The sepsisdetection_rhpam application is also a consumer on that topic. With consumption of a Patient resource, the RH-PAM process-engine embedded in the sepsisdetection-RHPAM application is invoked and a sepsis-detection business process is started.

   These business process and corresponding human tasks can be monitored via tools such as RH-PAMs dashbuilder component.

   1. As part of the sepsis-detection business process, the RESTful API of the HAPI FHIR server is queried for a list of all Observation resources for the Patient in a given time period and a PatientVitals resource is created.

   2. As part of the sepsis-detection business process, the PatientVitals resource is used as the payload of an HTTP POST request to the sepsisdetection-ml function. The function responds with an indication of whether sepsis is likely or not.

   3. As part of the sepsis-detection business process, a generateRiskAssessmentCommand message is sent (as a _Cloud Event) to RHT AMQ Streams.

5. The SepsisDetection-Risk service consumes the generateRiskAssessmentCommand Cloud Event. A FHIR R4 RiskAssessment resource (which includes the data indicating likelyhood of sepsis) is posted to the FHIR Server via its RESTful APIs.

   Debezium detects the addition of the Risk Assessment resource in the HAPI FHIR database and forwards this event as message to Red Hat AMQ Streams.

   RH-PAM picks up this change event with the Risk Assessment resource and advances the business process to the next task.

6. A user with a set of roles (defined in RH-SSO) authenticates into the SepsisDetection-UI. The sepsisdetection-ui interacts with RH-SSO (as per the Authorization Code Flow protocol of OIDC) to generate an Access Token. The sepsisdetection-ui interacts with the RESTful KIE-Server APIs (and includes the access token in the request) of sepsisdetection-rhpam and renders a user interface that allows for management of the sepsis-detection business process and corresponding human tasks. Depending on the role of the authenticated user, that user is presented with user tasks with which to work through their lifecycle.

7. The sepsisdetection-ui pulls in an IFrame from HealthFlow.

1. OpenShift Container Platform

   Sepsis dection demo has been tested on the following versions of OCP:

   1. 4.10.26

   2. 4.11.2

2. Resource requirements

   Resource requirements as needed by the app (doesn’t include resource requirements of Openshift to support itself) is as follows:

   1. RAM: 6 GB

   2. CPU: 8

   3. Storage: 10 PVCs of type RWO (no RWX requirement) and each of size 5 GiB

3. cluster-admin credentials to this OpenShift cluster are needed

4. wildcard certificate for routes

   Out-of-the-box install of OCP typically includes self-signed certs to secure the cluster’s routes. It is highly recommended that a wildcard cert issued by a well-known certificate authority (ie: LetsEncrypt) be applied to the cluster. If not, the sepsisdetection demo will successfully provision but the sepsisdetection-ui (as rendered in your browser) will not function correctly. In particular, CORS settings typically break when the various routes that your browser will need access to are secured using a self-signed cert.

5. oc utility (of version correspsonding to OCP cluster) installed locally

   All versions of this utility are available at either of the following:

   1. https://access.redhat.com/downloads/content/290

      RHN subscription required

   2. https://mirror.openshift.com/pub/openshift-v4/clients/ocp/?C=M;O=D

      Accessible without a RHN subscription

6. ansible installed locally

   ie: dnf install ansible

   1. On the host machine that will run the ansible, ensure that both kubernetes and jmespath ansible galaxy collections are installed for the version of python using by ansible:

      1. Check version of python used by ansible:

         $ ansible --version
         
         
         ansible [core 2.12.2]
           ...
         
           python version = 3.8.12 (default, Sep 16 2021, 10:46:05) [GCC 8.5.0 20210514 (Red Hat 8.5.0-3)]
         
           ...

      2. Install dependencies as root user:

         # python3.8 -m pip install kubernetes jmespath

7. git installed locally

1. Using the oc utility that corresponds to the version of OpenShift that you will deploy to, log into the cluster:

   $ oc login <OCP API Server url> -u <cluster-admin userId> -p <passwd>

2. Clone the source code of this project:

   $ git clone https://github.com/redhat-naps-da/himss_2021_sepsis_detection

3. Change to the ansible directory of this project:

   $ cd config_mgmt/ansible

4. Deploy to OpenShift:

   Note	If you are running the install from a Mac, it will be necessary to manually create the user1-sepsisdetection namespace prior to the step below.

   $ ansible-playbook playbooks/install.yml

   1. Deployment should complete in about 15 minutes.

   2. Notice the creation of a new OCP namespace where the application resides: user1-sepsisdetection

   3. At the completion of the installation, expect to see messages similar to the following:

      PLAY RECAP *******************************************************************************************************************************************************************************************************
          localhost                  :  ok=137  changed=77   unreachable=0    failed=0    skipped=14   rescued=0    ignored=0

5. Optional: Uninstall from OpenShift:

   $ ansible-playbook playbooks/uninstall.yml

Set the following environment variables with values similar to the following:

1. If testing locally deployed application (via docker-compose):

   export RHSSO_HOST=sso.local
   export RHSSO_URL=http://$RHSSO_HOST:4080
   export RHSSO_MASTER_PASSWD=admin
   export REALM_ID=kc-demo
   export retrieve_token_url="$RHSSO_URL/realms/$REALM_ID/protocol/openid-connect/token"
   export SEPSISDETECTION_RHPAM_URL=http://localhost:9080
   export FHIR_SERVER_URL=http://localhost:8080

2. Add the following entry to your /etc/hosts:

   127.0.0.1   sso.local

3. If testing environment deployed to OpenShift:

   SEPSISDETECTION_RHPAM_URL=https://$(oc get route sepsisdetection-rhpam -n user1-sepsisdetection --template='{{ .spec.host }}')
   RHSSO_URL=https://$(oc get route sso -n sepsisdetection-sso --template='{{ .spec.host }}')/auth
   REALM_ID=user1-sepsis
   retrieve_token_url="$RHSSO_URL/realms/$REALM_ID/protocol/openid-connect/token"
   FHIR_SERVER_URL=https://$(oc get route fhir-server -n user1-sepsisdetection --template='{{ .spec.host }}')

The application includes a HAPI FHIR Server that exposes RESTful endpoints.

1. Test HAPI FHIR Server CORS headers using a preflight request:

   $ curl -i -X OPTIONS -H "Origin: http://localhost:7080" \
       -H 'Access-Control-Request-Method: POST' \
       -H 'Access-Control-Request-Headers: Content-Type, Authorization' \
       "http://localhost:8080/fhir"
   
   HTTP/1.1 200
   Vary: Origin
   Vary: Access-Control-Request-Method
   Vary: Access-Control-Request-Headers
   Access-Control-Allow-Origin: *
   Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS,PATCH,HEAD
   Access-Control-Allow-Headers: Content-Type, Authorization
   Access-Control-Expose-Headers: Location, Content-Location

2. POST Demo Observation to FHIR server

   $ curl -X POST \
          -H "Content-Type:application/fhir+json" \
          $FHIR_SERVER_URL/fhir \
          -d "@sepsisdetection-rhpam/src/test/resources/fhir/DemoBundle.json"

3. POST Demo RiskAssessment to FHIR server

   $ curl -X POST \
          -H "Content-Type:application/fhir+json" \
          $FHIR_SERVER_URL/fhir/RiskAssessment \
          -d "@sepsisdetection-risk/src/test/resources/fhir/RiskAssessment.json"

The sepsisdetection-rhpam deployment is enabled with the kie_server as well as various endpoints that can consume FHIR payloads.

1. Retrieve an OAuth2 token using the sepsisdetection SSO client of the pre-configured SSO realm:

   TKN=$(curl -X POST "$retrieve_token_url" \
               -H "Content-Type: application/x-www-form-urlencoded" \
               -d "username=pamAdmin" \
               -d "password=pam" \
               -d "grant_type=password" \
               -d "client_id=sepsisdetection" \
               | sed 's/.*access_token":"//g' | sed 's/".*//g')
   
   echo $TKN

2. By setting fullScopeAllowed=true in SSO client, all roles assocated with an authenticated user will be included in the access token.

   These roles can be visualized as follows:

   $ jq -R 'split(".") | .[1] | @base64d | fromjson' <<< $TKN | jq .realm_access.roles
   
   [
     "interviewer",
     "kie-server",
     "user"
   ]

3. Health Check Report

   $ curl -H "Authorization: Bearer $TKN" \
          -H 'Accept:application/json' \
          $SEPSISDETECTION_RHPAM_URL/rest/server/healthcheck?report=true

4. View raw swagger json

   $ curl -H "Authorization: Bearer $TKN" $SEPSISDETECTION_RHPAM_URL/rest/swagger.json | jq .

5. View swagger-ui:

   Point your browser to the output of the following:

   $ echo -en "\n$SEPSISDETECTION_RHPAM_URL/rest/api-docs/?url=$SEPSISDETECTION_RHPAM_URL/rest/swagger.json\n"

   

6. List KIE Containers

   $ curl -H "Authorization: Bearer $TKN" \
          -X GET $SEPSISDETECTION_RHPAM_URL/rest/server/containers

7. List process definitions in JSON representation:

   $ curl -H "Authorization: Bearer $TKN" \
          -X GET -H 'Accept:application/json' \
          $SEPSISDETECTION_RHPAM_URL/rest/server/containers/sepsisdetection-kjar/processes/

8. List process instances for a deployment in JSON representation:

   $ curl -H "Authorization: Bearer $TKN" \
          -X GET -H 'Accept:application/json' \
          $SEPSISDETECTION_RHPAM_URL/rest/server/queries/containers/sepsisdetection-kjar-1.0.0/process/instances

9. Identify active node of process instance:

   $ curl -H "Authorization: Bearer $TKN" \
          -X GET -H 'Accept:application/json' \
          $SEPSISDETECTION_RHPAM_URL/rest/server/containers/sepsisdetection-kjar-1.0.0/processesses/instances/${pInstanceId}/nodes/instances | jq .[][0]

10. List user tasks given a list of roles in access token:

    $ curl -H "Authorization: Bearer $TKN" \
           -X GET -H 'Accept:application/json' \
           $SEPSISDETECTION_RHPAM_URL/rest/server/queries/tasks/instances/pot-owners | jq .

11. List user tasks as a Business Admin:

    $ curl -H "Authorization: Bearer $TKN" \
           -X GET -H 'Accept:application/json' \
           $SEPSISDETECTION_RHPAM_URL/rest/server/queries/tasks/instances/admins | jq .

12. List cases in JSON representation:

    $ curl -H "Authorization: Bearer $TKN" \
           -X GET -H 'Accept:application/json' \
           $SEPSISDETECTION_RHPAM_URL/rest/server/queries/cases/

1. Start HAPI FHIR server in debug mode:

   $ JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=*:5005,server=y,suspend=n"
   $ mvn clean package -DskipTests -Pboot
   $ java -DJAVA_OPTS=$JAVA_OPTS -jar target/ROOT.war

2. View bytea type in res_text field of public.hfj_res_ver table:

   fhir=# \d hfj_res_ver
                             Table "public.hfj_res_ver"
        Column     |            Type             | Collation | Nullable | Default
   ----------------+-----------------------------+-----------+----------+---------
    pid            | bigint                      |           | not null |
    partition_date | date                        |           |          |
    partition_id   | integer                     |           |          |
    res_deleted_at | timestamp without time zone |           |          |
    res_version    | character varying(7)        |           |          |
    has_tags       | boolean                     |           | not null |
    res_published  | timestamp without time zone |           | not null |
    res_updated    | timestamp without time zone |           | not null |
    res_encoding   | character varying(5)        |           | not null |
    res_text       | bytea                       |           |          |
    res_id         | bigint                      |           | not null |
    res_type       | character varying(40)       |           | not null |
    res_ver        | bigint                      |           | not null |

1. Build and install kjar project:

   $ cd sepsisdetection-kjar
   
   $ mvn clean install -DskipTests

2. Build KIE-Server executable from this project:

   $ cd sepsisdetection-rhpam
   
   $ mvn clean package

3. Build and Start app

   $ mvn clean package -DskipTests && \
            java -Dorg.kie.server.repo=../etc/sepsisdetection-rhpam/runtime_configs \
                 -jar target/sepsisdetection-rhpam-0.0.1.jar &> /tmp/sepsisdetection-rhpam.log &

4. Optional: Create a kie-container in kie-server (kie-container should already be registered as per contents of etc/rhpam/sepsisdetection-rhpam.xml )

   $ export KJAR_VERSION=1.0.0
   $ export KIE_SERVER_CONTAINER_NAME=sepsisdetection-rhpam
   
   $ sed "s/{KIE_SERVER_CONTAINER_NAME}/$KIE_SERVER_CONTAINER_NAME/g" etc/rhpam/kie_container.json \
        | sed "s/{KJAR_VERSION}/$KJAR_VERSION/g" \
        > /tmp/kie_container.json && \
        curl -u "kieserver:kieserver" -X PUT -H 'Content-type:application/json' localhost:9080/rest/server/containers/$KIE_SERVER_CONTAINER_NAME-$KJAR_VERSION -d '@/tmp/kie_container.json'

1. https://github.com/redhat-naps-da/sepsis-detection

2. https://gitlab.consulting.redhat.com/ba-nacomm/sepsis-detection/sepsisdetection-service/-/tree/master/openshift

3. https://gitlab.consulting.redhat.com/ba-nacomm/sepsis-detection/sepsisdetection-kjar

4. https://gitlab.consulting.redhat.com/ba-nacomm/sepsis-detection/sepsis-ui

1. ansible operator tutorial

2. HIMSS 2021 Sepsis Detection Operator Image Tags

The HIMSS Demo operator can be monitored by tailing its log file as follows:

1. Demo Onboarding request into RHPDS

2. agnosticd pull request