Architecture
With this project, we expect to bring tighter connections between patients, their family members, and doctors. As a start, we focus on the exchange of corresponding health and medical information.
Below is the current high-level architecture of OpenIoMeT - an open source project, which is made of those components:
A network compatible "Hub" for collecting data from passive sensors. Since not every sensor (e.g., a heart rate sensor in a sport watch) will actively push its data to another device, we'll firstly need a "hub" (e.g., could simply be an app installed in a smartphone) to collect data from sensor instead, then send the data to device gateway for further processing (e.g., format conversion, and sent to storage server).
A “Device Gateway”, is the one in between of medical devices and passive sensors, and Eir. It sends data to both the “Storage” and the “Analyzer”. One of its key jobs is to perform data format conversion (from different 3rd party's to desired structure for Storage, like what “shim”[1] does in open mHealth), in order to best fit the need of the “Analyzer” per use cases Eir intend to support. Those formats could be newly designed for Eir, or to leverage existing ones from open mHealth.
A "Storage", is a server that stores data collected from medical devices and passive sensors. In our plan the server is composed of two sub-modules: The first one, Eir Storage, is to keep data with structures newly designed for Eir; the other one is open mHealth’s storage solution, so Eir is compatible with open mHealth supported devices/sensors. (A good reference from open mHealth’s design principle of their data structure can be found here[2])
An "Analyzer", including a set of rules, is in charge of triggering an action once any pre-defined rule is matched, supported by data from device gateway, storage server and/or the "Crawler". It's the "brain" of Eir. The rules could be as simple as an information query from a user/doctor, to fetch desired data from storage then send back to the user/doctor; or to send a warning/notification to both user and doctor, when specific user health indicator appears abnormal than usual. A well-designed set of rules will be key to Eir's success.
A "Crawler", is the one that gets public 3rd party data and serves as the proxy of those data, to the Analyzer. Those data will be supportive information for certain "rules". The example of those 3rd party data includes location data from Google Map, weather data from weather.com, etc.
A "Web server" provides an interface for both users and doctors to interact with Eir. We will need a properly designed UI (that suits the size of the display in front of the user/doctor) and UX (simple to use) to facilitate the interaction.
A “User Gateway”, is a standard gateway in between user, doctors, and Eir.
Signaling server and WebRTC. We are also considering to facilitate a direct communication between a user and his/her doctor, hence, a quick advice from the doctor or simple Q&A can be provided in the case of emergency (note this part may be subjected to related local regulatory). WebRTC is the candidate technology for this purpose, and a Signaling server[3] will be hence needed.
[1] http://www.openmhealth.org/documentation/data-providers/about-shims/#/overview/get-started
[2] http://www.openmhealth.org/documentation/#/schema-docs/schema-design-principles
[3] http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-signaling
Based on the architecture and concepts above, we can conclude the following items as the data sources:
- Geolocation based data.
- Medical records, diagnosis and prescription from hospitals and doctors.
- Raw data from 3rd party medical devices.
To get geolocation based data, geolocation module and corresponding available APIs from other services(for example, Google Map APIs) are required. For diagnosis and prescription, we need to work on a better way and see how to integrate with existed systems in hospitals. For raw data from 3rd party medical devices, we proposed to use Simmer from mHealth to integrate with 3rd party medical devices.
Sandraghassen S Pillai [Ganesh] helped to start to identify vital signs by doing a survey with doctors. The following vital signs are identified as the most important factors and also the valuable data source we are looking for:
- Blood Pressure
- Pulse
- Temperature
- Respiratory Rate
- Oxygen Saturation
- Cardiac Rhythm
- Blood Sugar Level
Further survey with more doctors and more advice are expected next.