- 1 Eir: as known as Open IoMeT, a Community-led Project
- 1.1 About this project
- 1.2 Eir Connect
- 1.3 How to join?
- 1.4 Project plan
- 1.5 Bug list
- 1.6 Team members
- 1.7 Medical Consultant(s)
- 1.8 Reference
Eir: as known as Open IoMeT, a Community-led Project
About this project
First of all, this Wiki page is outdated. This project is now a 100% community program led by Kevin Hu. The new project Wiki is here: https://github.com/OpenIoMeT/Iomet-wiki/wiki
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.
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 data.
Problem Statements & Solutions
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 Source project, Eir, 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.
Eir 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.
Codename - Eir
We decided to use the code name, Eir, pronounced just like "Air", for this open source 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.
Market Size and Ecosystem
According to a June 2015 study from McKinsey & Company, the economic effect from cloud connected health technology could range between $170 billion to $1.1 trillion a year in the next 10 years. It explains the significant impact from solutions like Eir.
In the ecosystem, roles include users/patients/family members, hospitals/doctors/health-care organizations, research institutes, medical device manufacturers, insurance industry, and pharma industry. When it comes to cost savings, the insurance industry stands to benefit the most. Insurers will continue to push the technology innovations that reduce the amount of money they pay in claims, totaled more than $250 billion in 2015, according to the US Treasury Department. Innovations like these are of vital importance to $1 trillion pharma industry. The reason is easy to be understood: The sooner the doctors can detect illness, the sooner patients can start taking the drugs they need to manage or cure their conditions.
Mozilla won't host servers to keep data from patients. Instead, Mozilla initializes this project, works with community, and provide a total solution to anyone who is legally authorized to host the servers. This project has perfect match to Mozilla's mission, to bring more devices into the world of web, and allow patients to get timely diagnosis from doctors via web technology.
Concept of the project
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 Eir - an open source medical project, 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. 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” 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)
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.
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 will be hence needed.
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.
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
- Respiratory Rate
- Oxygen Saturation
- Cardiac Rhythm
- Blood Sugar Level
Further survey with more doctors and more advice are expected next.
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!!
- We have weekly meeting happened at 4pm every Wednesday(UTC+08:00).
- How to use IRC to get connected with others in the Mozilla projects
- Channels: #fxos-medical-platform, #b2g, #mozilla-taiwan
- Mailing list:
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.
In order to identify most valuable user stories and include them into the demo, we collect most significant pain points, prioritize them, and then pick 4 of them based on technical evaluation and also the major concept of this project. We put all our meeting notes regarding to the demo online. 4 chosen user scenarios are:
- Users get suggestions based on the health status / other information.
- Users get the suggestions to locate closest hospitals.
- The recovery status and health condition can be monitored.
- Users get reminders to take medicines or any other instructions given by doctors.
Then, we proposed to have the following demo scripts to represent the main idea of the first 3 user scenarios:
- A 70 years old Taiwanese elder who wants to join a marathon in London in 2016 June. To join a marathon is his/her dream. Due to some reasons, body condition for this user is actually not so proper for this, hence the health condition for this user has been mentioned for 3 months, together with regular appointment with a home doctor in Taiwan. This user is wearing a medical device that keeps monitoring the data, and sends to the home doctor via a smart-phone, together with geolocation & weather status. While the user is in London, the doctor from Taiwan find some abnormal of those indicators, hence suggests the user to find a proper hospital in London for further checks. The user then gets hospital suggestions from Eir.
- The doctor provides medical suggestions based on the weather and the health condition to this user who is in London, and decide if this user is capable of joining the planned marathon. A no-go advise is suggested from the doctor due to some abnormal health condition data, and the list of closest hospitals will be delivered to the user. Further health condition will be monitored and sent to the doctor.
Detailed planning and engineering items will be uploaded here soon.
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 firstname.lastname@example.org, or talk with us via any communication channels that we have for this program.
The dependency tree provides a good view of all bugs in this project.
35 Total; 0 Open (0%); 35 Resolved (100%); 0 Verified (0%);
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
- 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, Vishnudas Kulkarni, Ramdas Tekale, Vaishali Tekale
- 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]
- Singapore: Jason Wong
- Australia: Paul Theriault
- United States: Richard Paradies
- Germany: Christiane Ruetten
- 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
- Bangladesh: Bolaram Paul
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.