Eir: Difference between revisions
WeslyHuang (talk | contribs) (Remove "Eir" to align with other headlines) |
WeslyHuang (talk | contribs) (smaller thumbnail) |
||
| Line 24: | Line 24: | ||
[[File:MedicalPlatformConcept.png|center|400px|Concept of Medical Platform]] | [[File:MedicalPlatformConcept.png|center|400px|Concept of Medical Platform]] | ||
===Platform | ===Platform architecture=== | ||
Below is the current high-level architecture of Eir - our medical platform, which is made of those components: | Below is the current high-level architecture of Eir - our medical platform, which is made of those components: | ||
[[File:EirArchitecture.png|thumbnail| | [[File:EirArchitecture.png|thumbnail|x500px|center|Platform Architecture]] | ||
Revision as of 03:34, 19 February 2016
Eir - Open Source Medical Platform Project
About this platform
Background
With the aging population worldwide, there has been a rapid increase of dependent patients who are either bed or house bound. More and more services are provided by hospitals and health-care organizations and allow doctors to provide diagnosis in patients' places in a regular basis. But the frequency is not high enough to provide timely diagnosis based on latest update of health condition. It brings us the idea to implement a cloud based system that can monitor health condition of users and allows doctors to provide timely diagnosis.
Although there are lots of medical mobile apps on the shelf to provide personal medical information, analysis, or even some simple monitoring functionalities, these applications are used on current complicated operating systems that most aging patients may have difficulties to use. Another bigger issue is the lack of a centralized system to collect all these data from different medical devices and send these data to doctors as one single source of data for further diagnosis.
Therefore, the major goals of this project include:
- To provide a centralized place to collect data from different medical devices or apps automatically.
- To monitor health condition of users and allows doctors to provide timely diagnosis.
In October 2015, we raised this suggestion and initialized this project in National Central University. The initial target audience for this project focuses on the patients / users who are unable to go to hospitals and see doctors, and who would like to have a centralized place for all medical apps, and who are not familiar with existed complicated mobile operating systems.
Codename - Eir
We decided to use the code name, Eir, pronounced just like "Air", for this open source medical platform project. In Norse mythology, Eir is a goddess and/or valkyrie associated with medical skill. Eir is attested in the Poetic Edda, compiled in the 13th century from earlier traditional sources; the Prose Edda, written in the 13th century by Snorri Sturluson; and in skaldic poetry, including a runic inscription from Bergen, Norway from around 1300. Scholars have theorized about whether these three sources refer to the same figure, and debate whether Eir may have been originally a healing goddess and/or a valkyrie. In addition, Eir has been theorized as a form of the goddess Frigg and has been compared to the Greek goddess Hygieia.
Concept of the platform
With this platform, 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.
Platform architecture
Below is the current high-level architecture of Eir - our 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.
8. 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
Data sources
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 geo-location 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.
Problem Statements & Solutions
Problems Statements:
1. For elders, whether sick or not, to keep monitoring their health condition either by themselves, or by families or by their primary doctors is important. Those elders do not necessarily want to go to hospital very often but they still want to get medical advices or attention when they need/want to. A secured system that is able to provide an easy communication between patients, their family members, and doctors is therefore required.
2. Current remote medical service systems out there already solve the problems of collecting data from devices, patients and then sending to doctors, but they are either segregated or owned separately by doctors/hospitals. Patients do not own their historical medical/clinical data.
3. This Open Medical Platform means to solve this problem. All the data collected from each web-enabled devices are accessible to patients. Patients can decide whom the data should be sent to.
Value Proposition
Open Medical Platform connects the linkage among doctors/hospitals, patients & the web-enabled medical devices. With patients being the focal who keep updating medical information from devices to data center, doctors can easily provide Remote Medical Service to patients, whereas patients have permanent access to their medical information.
How to join?
If you are interested in joining us,
- Please sign up your name here. Please input your name, email, skills, Bugzilla account, and your country/timezone, then we will know how we can work together.
- Please refer to the following communication channels to join us!!
Communication Channels
- We have weekly meeting happened at 4pm every Wednesday(UTC+08:00).
- Meeting can be accessed via Vidyo client. Vidyo Room URL.
- Meeting minutes.
- IRC:
- How to use IRC to get connected with others in the Mozilla projects
- Channels: #fxos-medical-platform, #b2g, #mozilla-taiwan
- Mailing list:
- dev-fxos, dev-gaia
- Google Group: fxos-medical-platform
- Mailing list address: fxos-medical-platform@googlegroups.com
Target working environment
Based on our discussion, the benefit to run this system on a wearable device is better than on a mobile phone. To ask elders to carry a mobile device might be not a good suggestion. Instead, a wearable device is better. So, wearable is considered as a long term plan. We need to survey what kinds of wearable device is suitable for this project.
Before we found a good wearable device, the original plan is to work on existed Firefox OS mobile phones for the 1st version of this project. Later, based on some further discussions, in order to prevent some existed bias assumption on mobile phones and increase the availability to community and allow community members to have the same development environment in the early stage, Raspberry Pi 2 is considered as a good choice for phase 1.
Then, as the emulator is becoming mature, a good plan is to work on emulator environment before we find a solution on wearable devices. In order to make sure Firefox OS emulator will be easy to access by community members, a FxOS emulator promotion program is created.
Therefore, we can plan this project into the following phases:
- PHASE 1: Raspberry Pi 2
- PHASE 2: Firefox OS Emulator (Optional)
- PHASE 3: Wearable devices
Project plan
Based on the target working environment, we can have 3 phases for this project. In phase 1, the following actions are what we need to take next:
- To collect user scenarios, user stories, requirements.
- To prioritize requirements.
- To provide UI wire-frame.
- To enumerate engineering works on Bugzilla for phase 1.
- To estimate required efforts.
- To list down testing plan.
Now, we are collecting user scenarios, user stories and requirements. Please see our meta bug: Bug 1223309. All collected user stories are in Google Spreadsheet. Now, we put all our working items in a Trello board. Also, we put all our discussion results in a Google document as our meeting minutes.
2016 London Work Week
We are targeting to have our first demo in 2016 London Work Week. This demo could come with Raspberry Pi as a prove of concept device. Other than Raspberry Pi, a basic set of features on data center or data server is expected as well.
2015 Orlando Work Week
At 9am on December 11th 2015, we hosted a session in Mozilla Orlando Work Week. In this session, we had an overview of this program, and talked about the user stories, and the next plan.
After Orlando Work Week, we plan to refine user stories based on all comments that we collected during the Orlando Work Week. Then, we will submit these user stories into Bugzilla.
If you have any suggestions or comments, please send it to fxos-medical-platform@googlegroups.com, or talk with us via any communication channels that we have for this program.
Bug list
The dependency tree provides a good view of all bugs in this project.
35 Total; 0 Open (0%); 35 Resolved (100%); 0 Verified (0%);
Team members
Initially, there are totally 7 graduated school students, 1 PhD student and 1 3rd grade student who are led by Dr. Horng in the computer science department to work on this project. Dr. Horng, PhD., National Taiwan University, is a professor in National Central University now. His major research area is bioinformatics, and database.
Now, there are more and more community members, and students from computer science department and medical schools from different countries to join. These countries include Taiwan, Singapore, the United States, Malaysia, the Philippines, Mauritius, India, Germany, Bangladesh, Mexico, Spain and Netherlands. It indeed becomes a global program now.
All joined members are listed in a Google Spreadsheet and also listed in the following:
- Product management
- Taiwan: Kevin Hu
- Project management
- Taiwan: Wesly Huang, Kevin Hu, Rachelle Yang
- Engineering
- Taiwan: Greg Weng, Steve Chung, Ken Tsai, Ray Chung, Leo Chang, Iris Chiu, Ernest Chiang, Michael Tsai
- India: Kumar Rishav, Abhiram, Dron Rathore, Tanay Pant, Dyvik Chenna, Lavish Aggarwal
- Bangladesh: Bolaram Paul
- Malaysia: Arif Fahmi Fisal
- United States: Richard Paradies, Shawn Liu
- Philippines: Tito Mari Francis Escano
- Netherlands: Michiel de Jong
- Germany: Carsten Book, Aleh Zasypkin
- Mauritius: Sandraghassen S Pillai [Ganesh]
- Security
- Australia: Paul Theriault
- United States: Richard Paradies
- Germany: Christiane Ruetten
- Testing
- Spain: Isabel Rios
- Product marketing
- Taiwan: Natasha Ma
- India: Dyvik Chenna
- User experience / User research
- Taiwan: Mark Liang, Morpheus Chen
- India: Tanay Pant, Dyvik Chenna
- United States: Francis Djabri
- Medical experts
- Singapore: Tan Jit-Seng
Medical Consultant(s)
We invited Dr. Tan Jit Seng, who was a doctor in Singapore and now is a director at Lotus Eldercare Pte Ltd and providing elder health care service. Dr. Tan devotes himself in elder health care for years. He is dog-fooding Firefox OS and actively working on technical programming fields as well.
Dr. Tan is a medical consultant in this project and he is providing medical suggestions based on his experience in elder health care field.