Skip to content

Commit 896abef

Browse files
authored
Merge pull request #311 from ipbabble/add-emerging-disease-detection
Emerging Disease Detection - adding initial landing page and getting started
2 parents 0e97ebf + b061fee commit 896abef

File tree

5 files changed

+312
-0
lines changed

5 files changed

+312
-0
lines changed
Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
title: Emerging Disease Detection
3+
date: 2023-10-01
4+
validated: false
5+
summary: This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.
6+
products:
7+
- Red Hat OpenShift Container Platform
8+
- Red Hat OpenShift Serverless
9+
industries:
10+
- medical
11+
aliases: /emerging-disease-detection/
12+
pattern_logo: emerging-disease-detection.png
13+
links:
14+
install: getting-started
15+
arch: https://www.redhat.com/architect/portfolio/architecturedetail?ppid=6
16+
help: https://groups.google.com/g/validatedpatterns
17+
bugs: https://github.com/validatedpatterns/emerging-disease-detection/issues
18+
ci: edd
19+
---
20+
21+
:toc:
22+
:imagesdir: /images
23+
:_content-type: ASSEMBLY
24+
include::modules/comm-attributes.adoc[]:
25+
26+
== Background
27+
28+
Use case::
29+
30+
* Use a AI automation at the edge to detect emerging diseases.
31+
* Use an event driven architecture
32+
* Securely manage secrets across the deployment.
33+
+
34+
[NOTE]
35+
====
36+
Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
37+
====
38+
39+
Background::
40+
No technology is better poised to transform Healthcare as AI and Business Process Automation. Coupled with an Edge Architecture, these continuous monitoring and detection systems can scale to provide early warning intervention and measurable process improvements, anywhere.
41+
42+
Detection of disease states like sepsis, stroke, pulmonary embolism, and heart attack requires low-latency, broadband, asynchronous streaming capabilities. We have prototyped an early warning platform built with a distributed edge architecture, fed by at-home post-operative monitoring (fitbit, smart phone, wifi devices) and automated Clinical care escalation and coordination processes. This platform has the potential to significantly lower network traffic and cost while providing early warning interventions for our nation's Veterans.
43+
44+
[id="about-solution"]
45+
== About the solution
46+
47+
To demonstrate the effectiveness of the solution this pattern focuses on the specific problem of Sepsis. Sepsis is the body's extreme response to an infection. It is a life-threatening medical emergency. Sepsis is a costly and life threatening condition that can result in multi-organ failure. Beating conditions like sepsis requires rapid detection and mitigation of risks. With the immune system compromised, recovery at home is often preferred to minimize the risk for cross-infections, yet medical teams often lack the capability to perform constant surveillance for emerging risks across their patient cohorts, especially in rural settings. In this session, we will demonstrate an early warning system driven by Clinical AI at the Edge, fed by at-home post-operative monitoring and automated Clinical care escalation and coordination processes.
48+
49+
Sepsis is a costly and life threatening condition that can result in multi-organ failure. Beating conditions like sepsis requires rapid detection and mitigation of risks. With the immune system compromised, recovery at home is often preferred to minimize the risk for cross-infections, yet medical teams often lack the capability to perform constant surveillance for emerging risks across their patient cohorts, especially in rural settings. In this demonstration, we will follow a vulnerable, post-operative patient, Alani, as she recovers from surgery in her home setting.
50+
51+
== Technology Highlights:
52+
* Event-Driven Architecture
53+
* Mobile Engagement
54+
* Machine Learning
55+
* BPM+ Process Automation
56+
57+
58+
//figure 1 originally
59+
.Overview of the solution reference architecture
60+
image::emerging-disease-detection/edd-reference-architecture.png[Reference Architecture]
61+
62+
In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
63+
64+
//figure 2 originally
65+
.Sepsis Detection Workflow
66+
image::emerging-disease-detection/edd-sepsis-detection-ml-workflow.png[ML Workflow]
67+
68+
[id="about-technology"]
69+
== About the technology
70+
71+
The following technologies are used in this solution:
72+
73+
https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it[Red Hat OpenShift Platform]::
74+
An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
75+
76+
https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it[Red Hat OpenShift GitOps]::
77+
A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
78+
79+
https://www.redhat.com/en/technologies/management/ansible[Red Hat Ansible Automation Platform]::
80+
Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
81+
82+
Hashicorp Vault::
83+
Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
84+
85+
This solution also uses a variety of _observability tools_ including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
1+
---
2+
title: Getting Started
3+
weight: 10
4+
aliases: /emerging-disease-detection/getting-started/
5+
---
6+
7+
:toc:
8+
:imagesdir: /images
9+
:_content-type: ASSEMBLY
10+
11+
== Prerequisites
12+
13+
. An OpenShift cluster (Go to https://console.redhat.com/openshift/create[the OpenShift console]). Cluster must have a dynamic StorageClass to provision PersistentVolumes. See also link:../../emerging-disease-detection/cluster-sizing[sizing your cluster].
14+
. A GitHub account (and a token for it with repositories permissions, to read from and write to your forks)
15+
16+
For installation tooling dependencies, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start].
17+
18+
The use of this pattern depends on having a Red Hat OpenShift cluster. In this version of the validated pattern
19+
there is no dedicated Hub / Edge cluster for the *Emerging Disease Detection* pattern. This single node pattern can be extend as a managed cluster(s) to a central hub. See link:../../emerging-disease-detection/ideas-for-customization[ideas for customization.]
20+
21+
If you do not have a running Red Hat OpenShift cluster you can start one on a
22+
public or private cloud by using link:https://console.redhat.com/openshift/create[Red Hat's cloud service].
23+
24+
[id="utilities"]
25+
= Utilities
26+
27+
A number of utilities have been built by the validated patterns team to lower the barrier to entry for using the community or Red Hat Validated Patterns. To use these utilities you will need to export some environment variables for your cloud provider:
28+
29+
[id="preparation"]
30+
= Preparation
31+
32+
. Fork the link:https://github.com/validatedpatterns/emerging-disease-detection[emerging-disease-detection] repo on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes.
33+
. Clone the forked copy of this repository.
34+
+
35+
[,sh]
36+
----
37+
git clone git@github.com:<your-username>/emerging-disease-detection.git
38+
----
39+
40+
. Create a local copy of the Helm secrets values file that can safely include credentials
41+
+
42+
*DO NOT COMMIT THIS FILE*
43+
+
44+
You do not want to push credentials to GitHub.
45+
+
46+
[,sh]
47+
----
48+
cp values-secret.yaml.template ~/values-secret.yaml
49+
vi ~/values-secret.yaml
50+
----
51+
52+
*values-secret.yaml example*
53+
54+
[source,yaml]
55+
----
56+
secrets:
57+
- name: rhpam
58+
vaultPrefixes:
59+
- global
60+
fields:
61+
- name: rhpam_api_passwd
62+
value: kieserver
63+
- name: sso_siteadmin_password
64+
value: r3dh4t1!
65+
- name: kie_admin_password
66+
value: admin
67+
- name: kieserver_user_password
68+
value: kieserver
69+
- name: psql_passwd
70+
value: rhpam
71+
72+
- name: fhir-psql-db
73+
vaultPrefixes:
74+
- global
75+
fields:
76+
- name: psql_credentials_secret
77+
value: psql_secret
78+
- name: psql_user_name
79+
value: fhir
80+
- name: psql_user_passwd
81+
value: fhir
82+
----
83+
84+
When you edit the file you can make changes to the various DB and Grafana passwords if you wish.
85+
86+
. Customize the `values-global.yaml` for your deployment
87+
+
88+
[,sh]
89+
----
90+
git checkout -b my-branch
91+
vi values-global.yaml
92+
----
93+
94+
*Replace instances of PROVIDE_ with your specific configuration*
95+
96+
[source,yaml]
97+
----
98+
global:
99+
pattern: emerging-disease-detection
100+
hubClusterDomain: "AUTO" # this is for test only This value is automatically fetched when Invoking against a cluster
101+
102+
options:
103+
useCSV: false
104+
syncPolicy: Automatic
105+
installPlanApproval: Automatic
106+
107+
main:
108+
clusterGroupName: hub
109+
gitOpsSpec:
110+
operatorChannel: gitops-1.9
111+
----
112+
113+
[,sh]
114+
----
115+
git add values-global.yaml
116+
git commit values-global.yaml
117+
git push origin my-branch
118+
----
119+
120+
. You can deploy the pattern using the link:/infrastructure/using-validated-pattern-operator/[validated pattern operator]. If you do use the operator then skip to Validating the Environment below.
121+
. Preview the changes that will be made to the Helm charts.
122+
+
123+
[,sh]
124+
----
125+
./pattern.sh make show
126+
----
127+
128+
. Login to your cluster using oc login or exporting the KUBECONFIG
129+
+
130+
[,sh]
131+
----
132+
oc login
133+
----
134+
+
135+
.or set KUBECONFIG to the path to your `kubeconfig` file. For example
136+
+
137+
[,sh]
138+
----
139+
export KUBECONFIG=~/my-ocp-env/auth/kubeconfig
140+
----
141+
142+
[id="check-the-values-files-before-deployment-getting-started"]
143+
== Check the values files before deployment
144+
145+
You can run a check before deployment to make sure that you have the required variables to deploy the
146+
Emerging Disease Detection Validated Pattern.
147+
148+
You can run `make predeploy` to check your values. This will allow you to review your values and changed them in
149+
the case there are typos or old values. The values files that should be reviewed prior to deploying the
150+
Medical Diagnosis Validated Pattern are:
151+
152+
|===
153+
| Values File | Description
154+
155+
| values-secret.yaml / values-secret-emerging-disease-detection.yaml
156+
| This is the values file that will include the rhpam and fhir-psql-db sections with all database et al secrets
157+
158+
| values-global.yaml
159+
| File that is used to contain all the global values used by Helm
160+
|===
161+
162+
= Deploy
163+
164+
. Apply the changes to your cluster
165+
+
166+
[,sh]
167+
----
168+
./pattern.sh make install
169+
----
170+
+
171+
If the install fails and you go back over the instructions and see what was missed and change it, then run `make update` to continue the installation.
172+
173+
. This takes some time. Especially for the OpenShift Data Foundation operator components to install and synchronize. The `make install` provides some progress updates during the install. It can take up to twenty minutes. Compare your `make install` run progress with the following video showing a successful install.
174+
175+
. Check that the operators have been installed in the UI.
176+
.. To verify, in the OpenShift Container Platform web console, navigate to *Operators → Installed Operators* page.
177+
.. Check that the Operator is installed in the `openshift-operators` namespace and its status is `Succeeded`.
178+
179+
[id="using-openshift-gitops-to-check-on-application-progress-getting-started"]
180+
== Using OpenShift GitOps to check on Application progress
181+
182+
You can also check on the progress using OpenShift GitOps to check on the various applications deployed.
183+
184+
. Obtain the ArgoCD URLs and passwords.
185+
+
186+
The URLs and login credentials for ArgoCD change depending on the pattern
187+
name and the site names they control. Follow the instructions below to find
188+
them, however you choose to deploy the pattern.
189+
+
190+
Display the fully qualified domain names, and matching login credentials, for
191+
all ArgoCD instances:
192+
+
193+
[,sh]
194+
----
195+
ARGO_CMD=`oc get secrets -A -o jsonpath='{range .items[*]}{"oc get -n "}{.metadata.namespace}{" routes; oc -n "}{.metadata.namespace}{" extract secrets/"}{.metadata.name}{" --to=-\\n"}{end}' | grep gitops-cluster`
196+
CMD=`echo $ARGO_CMD | sed 's|- oc|-;oc|g'`
197+
eval $CMD
198+
----
199+
+
200+
The result should look something like:
201+
+
202+
[,text]
203+
----
204+
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
205+
hub-gitops-server hub-gitops-server-emerging-disease-detection-hub.apps.wh-edd-cluster.aws.validatedpatterns.com hub-gitops-server https passthrough/Redirect None
206+
# admin.password
207+
xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH
208+
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
209+
cluster cluster-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com cluster 8080 reencrypt/Allow None
210+
kam kam-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com kam 8443 passthrough/None None
211+
openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com openshift-gitops-server https passthrough/Redirect None
212+
# admin.password
213+
FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6
214+
----
215+
+
216+
The most important ArgoCD instance to examine at this point is `emerging-disease-detection-hub`. This is where all the applications for the pattern can be tracked.
217+
218+
. Check all applications are synchronised. There are thirteen different ArgoCD "applications" deployed as part of this pattern.
219+
220+
[id="viewing-the-sepsis-application-dashboard-getting-started"]
221+
== Viewing the Sepsis Detection dashboard
222+
TO-DO: Describe how to examine the various parts of the Sepsis application
223+
224+
= Next Steps
225+
226+
link:https://groups.google.com/g/hybrid-cloud-patterns[Help & Feedback]
227+
link:https://github.com/validatedpatterns/emerging-disease-detection/issues[Report Bugs]
42.6 KB
Loading
74.9 KB
Loading
167 KB
Loading

0 commit comments

Comments
 (0)