A Testbed for Personal HealthCare Slow Intelligence System

In what follows, we describe a Testbed for Personal HealthCare Slow Intelligence System. This testbed can be used for component-based SIS development.

System Description

The Personal HealthCare Slow Intelligence System (PHSIS) consists of many types of components, each type serves with certain funtionality, working together to solve complex problems. Components are communicating with each other through message, check out Message Types.

Below is a list of predesigned components right out of the box, you may also develop your own components of an existing type, or even a totally new type. You can check out Components / Roles for details.

(1) SIS Server: is technically not a component, but a forwarding center that processes and dispatches messages based on an existing routing table constructed with Register messages.

(1) GUI: is a predesigned Monitor component that monitors all Basic/Controller/Advertiser components within the current scope in the system. All properly registered Basic/Controller/Advertiser component will have its control panel here. You can adjust behaviors of each component individually.

(3) Input Processor: The Input Processor is a predesigned Basic component which takes in data stream generated by PaceTech machine and outputs readings for the various vital signals such as Blood Pressure, SPO2, EKG, etc.

(4) Uploader: is a predesigned Advertiser component which processes and propagates information to the outside world so authorized personnel can access said information.

(5) PrjRemote: is a predesigned Debugger component which can mock any well-formed messages, and capture any messages from any component to another component within a Scope.


The above diagram can be redrawn as an UML deployment diagram as follows.

The PrjRemote, the SIS server, the InputProcessor and the Uploader constitute the Component Infrastructure (see Chapter 15 on component infrastructure) . The other components are built with respect to this Component Infrastructure.

Component Types / Roles

There are 5 pre-defined Roles, Basic/Controller/Monitor/Advertiser/Debugger

(1) Basic Component: your average, run-of-the-mill guy who collects data, send out Reading, and occasionally send out Alert.

(2) Controller Component: can be responsible for processing Reading/Alert from Basic components, and occasionally send out Emergency.

(3) Monitor Component: watches over Reading/Alert all across a Scope.

(4) Advertiser Component: spots Alert/Emergency and tell the outside world about it.

(5) Debugger Component: like PrjRemote, can mock any well-formed messages, and capture any messages from any component to another component within a Scope.

Message Types

There are 7 pre-defined messages, Reading/Alert/Setting/Register/Confirm/Connect/Emergency, for actual definition of all existing message, check out Message Definition.

(1) Reading: a normal reading from a Basic component

Scope The operating level of this message
MessageType "Reading"
Sender Which component sends this
[Receiver] Optional, which component receives this
YOUR_OWN_ITEM_1
...
YOUR_OWN_ITEM_N
Date Date when this message is sent

(2) Alert: an alert from a Basic component

Scope The operating level of this message
MessageType "Alert"
Sender Which component sends this
[Receiver] Optional, which component receives this
YOUR_OWN_ITEM_1
...
YOUR_OWN_ITEM_N
Date Date when this message is sent

(3) Setting: a setting command, usually from a Monitor

Scope The operating level of this message
MessageType "Setting"
Sender Which component sends this
[Receiver] Optional, which component receives this
Purpose The purpose of this setting action, preferably no spaces, used for differentiate settings for a component
YOUR_OWN_ITEM_1
...
YOUR_OWN_ITEM_N

(4) Register: a registration request

Scope The operating level of this message
MessageType "Register"
Role Basic / Controller / Monitor / Advertiser / Debugger / YOUR_OWN_ROLE

* Unless behaviors added to SISServer otherwise using your own customized role here won't do anything.
Name Name of the component, no duplicates allowed for one Scope
[InputPath] Optional, for Controller components only, provide the location of all required sources to build a Controller component, leave blank to use default /ControllerComponents folder
[OutputPath] Optional, for Controller components only, provide the location to put the generated Controller component, leave blank to use default /Components folder

(5) Confirm: a confirmation from SISServer

Scope The operating level of this message
MessageType "Confirm"
Sender Which component sends this
Receiver which component receives this

(6) Connect: a connecting request from a component other than Monitors

Scope The operating level of this message
MessageType "Connect"
Role Basic / Controller / Monitor / Advertiser / Debugger / YOUR_OWN_ROLE

* Unless behaviors added to SISServer otherwise using your own customized role here won't do anything.
Name Name of the component, no duplicates allowed for one Scope

(7) Emergency: a emergency message from a Controller component

Scope The operating level of this message
MessageType "Emergency"
Sender Which component sends this
MainComponent The Basic component initiates the emergency
HelperComponents All other Basic components which provide useful information
Note Additional Note
Date Date when this message is sent

System Installation

Download SISv5n2.zip, unzip and follow the installation instructions in ReadMe_V5.txt

The additional software package for SIS and Android development can be downloaded from SISv5android.zip

Complete SIS and Android Studio installation instructions can be found at ReadMe_V6.pdf

Preliminary Condition

SIS Server and PaceTech machine pre-exist or have already been instantiated.

GUI, InputProcessor, BloodPressure/SPO2/EKG Monitor and Uploader will be instantiated.

In case some of these components are not available, it is still OK. You can use the PrjRemote to mock messages from these components. Messages to these components will be ignored by the SIS Server, but still displayed in PrjRemote since that's how a Debugger component rolls.

For the class projects, for example, you can mock messages from InputProcessor. Therefore, you don't need to have access to the PaceTech machine to develop and test your plug-in components.

Initialization

You can use a Debugger component like PrjRemote to mock Register message(s), or simply use the batch script provided: Scripts/runIndividualComp/runInitializer.bat

PrjRemote sends Register to SISserver to enable message forwarding for GUI

PrjRemote sends Register to SISserver to enable message forwarding for InputProcessor

PrjRemote sends Register to SISserver to enable message forwarding for BloodPressure Monitor

PrjRemote sends Register to SISserver to enable message forwarding for SPO2 Monitor

PrjRemote sends Register to SISserver to enable message forwarding for EKG Monitor

PrjRemote sends Register to SIServer to enable message forwarding for Uploader

A Scenario

PachTech machine send out input to InputProcessor, which parses the data and extracts vital signals. (InputProcessor accepts sensor data input and produces InputProcessorBloodPressureSetting / InputProcessorEKGSetting / InputProcessorSPO2Setting. However sensor data input may not be a formatted message)

InputProcessor sends InputProcessorBloodPressureSetting (a "Setting" message) to BloodPressure Monitor, which checks for abnormality. There could be a knowledge base, but initially we just check if systolic reading is over 140 or diastolic is over 90 to generate a BloodPressureAlert. (BloodPressure Monitor accepts InputProcessorBloodPressureSetting from InputProcessor, generate BloodPressureReading / BloodPressureAlert)

BloodPressure Monitor sends BloodPressureAlert to GUI, which displays the vital signals. (GUI accepts "Reading" / "Alert")

BloodPressure Monitor sends BloodPressureAlert to Uploader, medical conditions to remote database. (Uploader accepts "Alert" / "Emergency" and uploads it. The uploading may not be a formatted message)

(There are other messages and other components for heart rate, SPO2 level, EKG signals for irregular heart beats, etc. But it is the same scenario, only more complicated. The GUI may also need to display the combined vitals.)

Design Considerations

A monitor component and the associated knowledge base component can be considered as one coarse grained business component. The refined monitor component and the associated knowledge base component are the fine grained components. (See Chapter 16 on business components.)

A component is brought to life by the "Register" message.

When a component first comes to life, it should send a "Connect" message to the SISserver.

SISserver will return an "Confirm" message to the said component.

The "Activate" message and "Deactivate" message will activate/deactivate the said component.

Finally, the "Setting" message with the purpose of "Kill" will destroy it.

Component Specification

We need to specify at least the input messages, output messages, the variables (attributes) and the methods for the components. Therefore the class diagrams should be prepared.

For a complete specification we can use the following UML diagrams: The use-case diagram specifies the major use-cases (or components). The sequence diagram describes the interactions among the classes and actors based upon messages. The state diagram describes the state transitions for the major component(s).

Special attention should be paid to the interface. For more details about interface see Chapter 17 on Components and Connectors.

How to setup SIS server and prjRemote under JDK Apple

The following readme text file explains how to set up SIS server and prjRemote under JDK Apple.