Closed MatthewVita closed 4 years ago
although I still have no email reponse, these are the components I asked for:
ECG Electrocardiogram Sensor PRO for MySignals (eHealth Medical Development Platform)
SPO2 Pulse Oxygen in Blood Sensor PRO for MySignals (eHealth Medical Development Platform)
Blood Pressure Sensor PRO for MySignals (eHealth Medical Development Platform)
Awesome! Great work @andremillet
@bradymiller let me know if you think the board would be cool with paying for these test devices. If not, I'll foot the bill.
It will be a total of $464.78 + shipping... so maybe $500ish
BTW, the only way this wont work is if they don't support our ask to bypass this thing:
...this is their "CPU", but it's not cheap. We want to wire up own our with RaspberryPIs. However, that may make them a tad worried because it's getting around part of their business model... If this does happen, I say we do something very crazy and NOT open source the RaspPI code. Afterall, this work is not meant to be a first class feature in OpenEMR (devices, I mean... inpatient will be). This is a crazy idea, but I think we'll be fine because suggesting users use these devices is not-FLOSS friendly in the first place and we won't upset a core partner (MySignals). To expand on this, we can co-engineer the cheap RaspPI solution and give the code to MySignals with an agreement that they will not increase the price of a readymade RaspPi solution (this is important as we don't want users having to manufactor the stuff themselves). This is a win-win for everyone. At this point, I will make it a point that this is Matthew Vita as an independent person doing this solution and not OpenEMR. I want to make it very clear that this would be exiting the FLOSS-realm, but it's practical and has great intentions.
BTW, this stuff is all a bit crazy because these are not "medical devices" so this may be a hard sell lol. They are for "research only" so I want to be very careful here, esp. with my ask for board funds (which I'm starting to think is a bad idea and I should just work on this stuff outside of the project?)
@robertdown I would like your thoughts on this topic. You have a great grasp on ethics and I would like to get your take!
I think it is worthy to check this link: https://www.cooking-hacks.com/ehealth-sensors-complete-kit-biometric-medical-arduino-raspberry-pi
there is a 1.0 discontinued kit that works with 4 sensors. may be we can find cheaper at ebay On Tue, 1 Aug 2017 at 00:41 Matthew Vita notifications@github.com wrote:
BTW, the only way this wont work is if they don't support our ask to bypass this thing:
...this is their "CPU", but it's not cheap
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openemr/openemr/issues/978#issuecomment-319259257, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiTSS-LPREayk480r1LV0XYyivvChZyks5sTp53gaJpZM4Ooszg .
@andremillet brilliant. I just used the Wayback machine to see the page in an older form and they were asking €450.00 for it, which is a tad costly but reasonable in comparison to the CPU they are offering now
BTW, Ebay is a bad idea because we need a strong partner that is currently manufacturing the hardware. If go with the Ebay route, there's only a finite amount left. Remember that we want end users saying "okay great, this solution has been tested as a 3rd party add on with OpenEMR and there is an active professional company from which I can buy hardware from". This is kind of like when we test OpenEMR with lab vendors, which are 3rd party non-FLOSS solutions.
Perhaps we can partner with MySignals to see if we can get them to make us these older boards with a nice case. I realize this is very much entering the non-FLOSS arena, so I think it is best to wait on Robert's comments on the ethics of this and then we can maybe continue all of this device work outside of the OpenEMR project (Team Epsilon or just use one of personal repos).
ok. I will keep searching. They seemed to have a strong open source core so my guess is that it has started as a non-profitable project. If this 'ground zero' can be found, may be we could continue this version, if there was any in the past On Tue, 1 Aug 2017 at 00:57 Matthew Vita notifications@github.com wrote:
BTW, Ebay is a bad idea because we need a strong partner that is currently manufacturing the hardware. If go with the Ebay route, there's only a finite amount left.
Perhaps we can partner with MySignals to see if we can get them to make us these older boards with a nice case. I realize this is very much entering the non-FLOSS arena, so I think it is best to wait on Robert's comments on the ethics of this and then we can maybe continue all of this device work outside of the OpenEMR project (Team Epsilon or just use one of personal repos).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openemr/openemr/issues/978#issuecomment-319261001, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiTSY1sTbQZcJ7d49Y73blWVv_RL8DFks5sTqI3gaJpZM4Ooszg .
It's possible. I'm thinking if we were just some random person on the internet asking for the old version, they would say no. However, since we can possibly open up a small stream of business from our end user population, they may be willing to talk
Sergio answered the email, and I forwarded it to you, so you could take a look at the technical details.
In this link you have the technical documentation about how to use both methods.
I see. Can you ask him if the old hub can be used instead? Perhaps mention our OpenEMR user base may provide a steady stream of revenue for them because they low-cost devices such as these will be documented as tested/integratable. The users, however, cannot afford the more expensive components such as the hub
Done. Waiting for an answer.
André Millet
2017-08-01 16:11 GMT-03:00 Matthew Vita notifications@github.com:
I see. Can you ask him if the old hub can be used instead? Perhaps mentioned our OpenEMR user base may provide a steady stream of revenue for them because they are looking for low-cost devices such as these and cannot afford the more expensive components such as the hub
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openemr/openemr/issues/978#issuecomment-319467707, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiTSXeN2BQiKhdZM8LrN7kt41wzQPwoks5sT3hYgaJpZM4Ooszg .
received the following answer:
I regret to say that sensors are not >compatible with the old version of >MySignals ("eHealth Platform"). If you need further information, please >contact me.
My suggestion is that we still try to acquire this first version somehow, for testing purposes only
I may actually be somewhat helpful here! This is what I studied in undergrad. The difficulty with some of these solutions is the testing infrastructure behind them. Much of the cost of these devices comes from the certifications that they will work as expected. Cleaning and trimming the signals is easily as important as simply gathering them. The other issue that may be relevant is that certain hardware lends itself to signals acquisition. The raspberry pi, for example, doesn't have an ADC (to my last recollection), which would prevent us from simply jamming sensors into it, and necessitate the design of additional hardware (chip-based ADCs, noise filters, etc.) in order to get the signals in. With a goal of putting together a low-cost hardware offering, it would be great to get some industry thoughts, especially when it comes to regulatory requirements, since the FDA is super strict about these things, and I'm sure other nations' governing bodies are as well. I'll try to get in contact with my friend at GE, and hopefully she might be able to point us in a positive direction as well. This will definitely be a huge value-add for ERs in many nations, and it's exciting to see people working toward it!
awesome, Jason! thx in advance!
@TheToolbox sounds great! We need more resources for this project as it is ambitious.
As far as FDA strictness, we may not have as much to worry about in other countries. This is good because that means we can make use of more unorthodox solutions (for instance, the products Andre and I are looking at "are not medical devices" :) ) - since we don't have to provide any warranties with anything because we're open source, this may work for a lot of non-US users that are not as lucky when it comes to finances (medical devices, as you know are VERY expensive. One US-style EKG is the cost of all of these little bluetooth/rasppi solutions)
I should be clear that this does NOT mean we don't care about quality or testing. I am willing to spend personal funds buying and testing these devices for us. We just can't guarantee anything. This is in line with our license:
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
I have a little story. So, up until recently, my wife's glucose monitor was not to be taken literally. If it said that she had a high or low glucose number, it was instructed that she actually take a reading with an FDA approved "finger prick" device. Recently, the company got FDA approval for the monitor to be taken literally (and it was always accurate for her anyways).
This may be an approach that can be documented (read: documented, not advised) should one of the bluetooth/rasppi solutions "act up", maybe it would be good to use a manual approach. Heart rate of 999 may be suspect :) (although I think @andremillet and I have a heart rate of 999 with excitement looking up all of these devices!)
although I think @andremillet and I have a heart rate of 999 with excitement looking up all of these devices!
It's over 9000*! lol
I think we're going to try to sponsor a challenge at an upcoming medical hackathon for a group of engineering, medical, and CS students work on creating an open source, low-cost medical device. The areas I'd like to see are a glucometer, a vital signs matching, and a portal EKG device. I'm still working on the details but do keep this in mind. I'm also trying to get my university and perhaps the hospital I work out to offer sponsorships.
Okay sounds like a plan. We'll play it by ear
I was able to talk a bit with the handful of engineers I know out in the field. The general consensus was that putting new hardware options together is not an easy task. Interestingly, security factored highly in their considerations, which is an issue I think we are more than capable of tackling without undue difficulty. The other concerns that they expressed, similar to what I had said, is that any devices would have to clear the bar of "are you better off with the device than without it". This may seem obvious, but actually knowing that this bar has been cleared is not always so apparent. While an EKG may look like a good pattern, verifying its usefulness is a very different matter. Pulse oximeters and auto bp cuffs present much easier targets due to their lower-bandwidth, higher-error-margin natures, and I'd definitely recommend attacking them first.
The other suggestion that was made was to find out what organizations like Doctors without Borders are using in the field. Perhaps those options are cheap already, and integrating with them or improving on them might be an easy win for us.
As an aside w.r.t. liability/legality, my understanding is that (in the US, which likely wouldn't be our target anyway) not only would non-certified devices have to state no guarantees, but more explicitly would have to call themselves non-medical devices. Hopefully this would be much less of a concern in the places that would most benefit from cheap hardware. It would be interesting to see an openMedicalHardware project started up in parallel to openEMR, since it would take a large effort to move in that direction. Perhaps there are existing groups with similar goals that could be merged/worked with.
My final thoughts are that easier devices should be attempted first, and a solid common brain-piece should be selected and vetted before moving on to sophisticated diagnostic tools. I don't know if a Pi can keep up with a 500(?)hz EKG signal, but if it is the right tool for this job, then perhaps an adc like the ads1115 or something fancier like the ads1263 would be appropriate for signal acquisition. A large list of available options can be found here. Sensors/Probes I suspect might be easier to come by, which is good, but they may be more expensive per unit. Hopefully some of these ramblings give insight.
Suggest migrating this to the forums, it's better suited for these longer form conversations.
Suggest migrating this to the forums, it's better suited for these longer form conversations. I second that.
André Millet
2017-08-08 18:34 GMT-03:00 Robert Down notifications@github.com:
Suggest migrating this to the forums, it's better suited for these longer form conversations.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openemr/openemr/issues/978#issuecomment-321088615, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiTScNNh8AfO1BmAO12vXkey3JLXV22ks5sWNSAgaJpZM4Ooszg .
This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.
This issue has been automatically closed because it has not had any recent activity within the past 97 days.
We wish to provide an affordable and high-quality hardware solution in order to be compliant with an API being developed for OpenEMR. In doing so, less financially-strapped hospitals will become at parity with the "data centric" style of US HIT.
For more information on MySignals: http://www.my-signals.com/#what-is-mysignals
Note: This ticket is for tracking Andre and Matthew's work.