Bhutan description: (Thanks, Wikipedia) A landlocked country in South Asia located in the Eastern Himalayas. The country’s landscape ranges from lush subtropical plains in the south to the subalpine Himalayan mountains in the north, where there are peaks in excess of 7,000 metres. Bhutan is a developing nation and has a government based national health system with only a few hundred doctors. Patients can visit their doctor via traditional means or via helicopter for more serious situations.
Problem: After trying out Napier, a nonfree EHR that was expensive, slow, and couldn’t be customized, the doctors have moved back to a paper solution. The doctors do not like EHRs because of limited typing ability and scribes cannot be brought in due to a lack of resources, both in medical students to act as scribes and the sheer costs of such a role. Despite a lack of interest in EHRs, there is a healthy interest in setting up an electronic solution for patients to report their self measurements, based on provider orders. For instance, if a patient is hypertensive, the doctor wishes to see daily trends of the vitals rather than not being aware until a patient visit (with less information). The same use case exists for other conditions such as diabetes (glucose readings) and pregnancy (weight changes, first kick, etc) with the latter being a tad more nuanced.
Solution: The vibrant and volunteer OpenEMR community will develop an independent self measurements module with a generic interface for SMS (text message) services. With this solution, the provider can set up measurement rules and patients will be asked to input vitals on an interval basis. Providers will be able to trend data over time to provide better healthcare, without the need of an extensive patient trek to get to the practice. Users will be to use the module independently (cloud or self hosted) or within OpenEMR. Because SMS services are almost always nonfree, an interface will be provided and the wiki will document nonfree API interaction examples to comply with GNU. Dr. Pelgay Jamyang will work with us to test out the solution in his practice. If it’s a success, the feature will be rolled out to all Bhutan practices.
All Github issues (including mockups!) for the project can be found here: Remote Patient Vitals Module · GitHub - we need to put together a team ASAP!
Hi @Elijah_Wisdom, things have been bumpy but I actually had some contractors put together a basic version of this with Twilio! They did a great job to get it started, but obviously they don’t know about all of the various practices/patterns in OpenEMR. Should be a matter of cleaning up the code and QA’ing it. Also, we have to check in with our friends in Bhutan of course.
Hi everyone!
We’re working on a tool which allows users and/or medical personnel to track vitals remotely and it’s also has OCR functionality which automatically recognises medical devices values (blood pressure and oximeter at the moment and glucometer is on plan) and sends data to the EMR/EHR system.
Brief description is here http://health-data.tilda.ws/rpmsolution
Please let me know if this is interesting for the OpenEMR community?
Thank you
Hi All,
Just wanted to let you know that we also have added some Machine Learning (AI) capabilities which get patient vitals and make predictions on hypertension possible problems.
Data is taken from OpenEMR and now put into patient related info so that medical personnel can see it and take necessary actions. I’ll provide you with a demo video later on but please let me know if you are interested in such soultions?
This would be of great value even for urban patients with various risk profiles. Almost all products like this one have traditionally focused on online data entry for billing purposes. Meaningful Use requirements have coerced the developers towards actual patient care.
We for one would be very interested if these type of solutions are set up as add-on projects that can be loosely coupled with OpenEMR to be free of any stack limitations or skills constraints. These capabilities will be also a great dividend for all infra work put in by @sjpadgett and @adunsulag towards FHIR.
Looking forward to the details.
ps: Suggest discussion be in a separate thread that MU refers as Patient Generated Data.
At the moment this is more like a standalone python app with the idea that it go through the patients, evaluate them and adds an ML conclusions into patient related entity/fields.
However, our next step will be to make this a module that can be registered and installed in the codebase.
I meant software. This is a web app which can be opened via mobile and then photo of a medical device screen (now blood pressure and oximeters are supported) can be made via the phone and then it got recognised and data put to EMR
I just wanted to update you that we were able to implement a POC for a Module with machine learning which uses PHP only (without Python).
Prediction model now has 69,3 accuracy for hypertension and we’re working to increase it.
I have a few questions:
Where you think is the best place in the system to put machine learning algorithm outcome? I think about “Medical problems” or “Clinical Note” but maybe there are some other better fields?
Is there a way to connect to real health practice to do some closed alfa and beta testing?
Hi Timur,
If the module uses the vital sign data from the EMR we would be interested in testing it. We specialize in RPM, so we have lots of collected data to work with.
In regard to your question on where to store the data - my first instinct says Clinical Note, but that is just one opinion. We store our RPM observations as clinical notes.
I am assuming this is predictive model. If so, it is better to create a completely different structure, preferably just a pid(primary key) with model tracking info and predictive output as longtext as json. This will let developers and users track accuracy over time. It will also keep clinical data undisturbed as it can have severe implications if it appears that clinicians knew about a condition (e.g. hypertension) and did not act on it.
Bigger question will be how and who should be notified that e.g. 30 patients out of 2000 were tagged by your model. What they will do about it is beyond my pay grade. One of the challenges for small practices this product targets is that the staffing levels are barely enough to meet operational needs. So there is no down time for anyone to retrieve and processes this type of data systematically. Regardless, it would be great to have that and more such information available in case anyone chooses to use it well.
I will be glad to work with you on that project using our remote patient monitoring devices , we also have mobile app that collect data from the patient using voice as well
Thank you
Shamly
Hi @claireshut,
We ended up using OpenEMR api and separate mobile SDK and Mobile apps which collects data using PPG technology and put it into OpenEMR.
PHP module didn’t go far from PoC.
If smartwatches you use have an open interface or provide data which chan be used, the the easiest way would be to do the same - put it to OpenEMR using OpenEMR API.
We can chat about that in more details and see if we can collaborate in that direction.
