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 |
Download SISv5n2.zip, unzip and follow the installation instructions in ReadMe_V5.txt.
(Note: There is a patch, NewTranslator.java, to fix an issue with code generation)
How to setup SIS server and prjRemote under JDK Apple:
The following
MacReadMe.txt explains how to set up SIS server and prjRemote under JDK Apple. It is also included in ReadMe_V5.txt as Section 5.
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.
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.