Eir: Difference between revisions

===Platform architecture===

Below is the current high-level architecture of Eir - an open source medical platform, which is made of those components:

1. 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).

2. A “Device Gateway”, is the one in between of medical devices and passive sensors, and Eir platform. 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.

3. 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])

4. 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.

5. 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.

6. 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.  

7. A “User Gateway”, is a standard gateway in between user, doctors, and Eir platform.