zhhealthcare wrote on Monday, May 07, 2012:
How would one go about designing an integration for medical devices data? We were thinking of developing an application that would be installed on the local machine that would communicate with the local machine and upload those files to the OpenEMR webserver(encrypted). This is a high level view. Is there anyway to avoid the local machine app?
Any views on this?
Regards
Shameem
sunsetsystems wrote on Monday, May 07, 2012:
This is similar to the problem of scanner support. To avoid a local app (i.e. talk directly to the server) you’d need the device to support some sort of network protocol, including encryption if that is required.
zhhealthcare wrote on Monday, May 07, 2012:
Thank you, Rod for the quick response. I don’t think all the devices out there will do that: internet support. I guess then there is no choice but to write an app which can hopefully be flexible enough to capture data from all the various types of machines.
Hope this approach is acceptable to the community? Do you find the approach sound?
Thanks
Shameem
sunsetsystems wrote on Monday, May 07, 2012:
Sure, but keep in mind that one reason OpenEMR is browser-based is to support a wide variety of computing platforms. So IMO it’s important to choose development tools that will target at least Windows, Linux and Macs.
The other challenge is the open source perspective when dealing with device vendors. Try to choose vendors that are flexible enough to support open protocols and don’t consider the information provided to you to be confidential. You might find that difficult, I’m not sure.
sunsetsystems wrote on Monday, May 07, 2012:
You might have better luck writing an app that just sends the contents of a directory on the client to the server, and corresponding code on the server to accept it. That way you can use whatever the vendor provides to store results, and you don’t have to worry about talking to the devices.
zhhealthcare wrote on Monday, May 07, 2012:
Of course, we will push hard for Open source. We will try something that is cross platform. That is in our interest too.
Shameem
zhhealthcare wrote on Monday, May 07, 2012:
I am assuming that data from the machine will not contain any correlation to identify the patient info. The folder thing will work only if PIDs can be identified from each data. The app can help store the correlation while it is being stored. So what they need to do would be open the app, put in the PID and then read(from machine) and store the data.
Am I missing something?
Shameem
r3gllc wrote on Monday, May 07, 2012:
One thing will be important to keep in mind is the new FDA rules for MDDS (Medical Device Data Systems).
The other thing, that will be important for an OpenSource project like OpenEMR is choosing the correct interface standard that is recognized globally, not only in US. Though a new field, already there have been few standards (or not standards) that is used by different medical devices. Though it seems that the ISO 11073 standard will be the primary standard (or the umbrella standard) for medical devices at it is built with close connection with other health related standards (such as HL7, DICOM, IHE, SNOMED etc)
yehster wrote on Monday, May 07, 2012:
It’s going to depend a lot on the device.
For example, most EKG machine prompt the user for patient details before it will capture information. In an emergency situation, (i.e. if the patient might be having a heart attack) you can put fake info quickly and just get the trace, but devices usually want to know who the patient is in order to store the data too.
r3gllc wrote on Monday, May 07, 2012:
yehster… this is exactly why FDA wanted to introduce the rule for Medical devices interfacing with EMR systems …as with the interfaces the data will be captured automatically from the devices to the EHR system which will be used for continuing healthcare - there is no human intervention (and as such accountability). Based on this data if any wrong treatment happens (willingly or unwillingly) and by providers who are not privy of the situation, it opens up a new set of legal questions of accountability , ethics etc. To make the matter worse, with multiple systems getting involved the point of failure also increases … But these only stifle the innovation … If I can recall correctly John Halamka (CIO of Harvard medical) mentioned this dilemma of innovation vs quality control in the medical device interfaces in one of his blog post …i will try to dig it up…
zhhealthcare wrote on Monday, May 07, 2012:
@r3gllc I am considering Mirth and HL-7. I suppose that should take care of that.
@yehster Can I take that as a given that most machines do have patient information?
What are the machines that are most commonly used?
I am thinking that once this app is developed we can include other stuff that needs to be stored including jpegs, or video consults… getting too ambitious here.
Shameem
zhhealthcare wrote on Monday, May 07, 2012:
@r3gllc Can you summarize what the new FDA rules mandate?
Shameem
ajperezcrespo wrote on Monday, May 07, 2012:
Sam,
Take a look at this thing
Opensource multiplatform medical device interface
https://github.com/freemed/freeshim
Alfonso
r3gllc wrote on Monday, May 07, 2012:
This is the rule
http://www.gpo.gov/fdsys/pkg/FR-2011-02-15/pdf/2011-3321.pdf
And it is well described in this blog entry by john-
http://geekdoctor.blogspot.com/2011/05/medical-device-data-systems.html
zhhealthcare wrote on Monday, May 07, 2012:
@r3gllc
I read the post and the rule. What I understand is that any software that transports the information is presumed as an MDDS and requires certification. If this is so then open source is again kicked in the bottom(classy way of putting it)
Am I reading this correctly?
Shameem
r3gllc wrote on Tuesday, May 08, 2012:
I understand your frustration . I think this is probably from your experience in getting ONC certification - correct?
But, in my opinion these rules are much better compared to the ONC EMR certification… .As rightly mentioned by John - “The regulation strikes an interesting balance - how to encourage innovation while also requiring accountability for errors that result from software or hardware defects”
I have interacted with several people globally and have been in the data interface industry for a while - With that experience, in my humble opinion, the FDA rules are common place (similar rules are there in all developed countries, in-fact in europe they are worse, they have one set for each country and then one for EU), while compared to that the ONC certification rules were just “artificial rules, invented by the big vendors” to stop small vendors and any and all opensource penetration in EMR market (remember the first version of the CCHIT certification). …I really feel sorry that some of the greatest opensource healthinformatics ideas, which are conceived in our(US) universities cannot be implemented in US due to this “artificial, unnecessary certification criteria” … but that is a different topic and the boat on that had already sailed … 
Coming back to the FDA rule - Yes, the FDA cert might be required for this interfaces but that is very similar to so many other industrial automation systems and most of them gets that from the federal agency as long as they stick with some type of standards such as the open OPC standard for industrial automation …
I really don’t want to stifle your innovation with this information, as what you are trying to do is a great effort and one of the very important one in the healthcare/ medical - infact, in the 2011 Scientific american among the 10 world changing ideas the first one was a "a list of forever health monitor " that interacts with medical devices - It is predicted that, these “always on” MDDS systems may reduce 75% of healthcare spending for chronic disease mgmt and extend life expectancy …
So, I think, as long as you stick with the open standards you should be okay, if FDA cert is required … worst case situation, FDA can stop your interface in US, but other parts of the world can still use it (or at-least get the idea to move forward)
zhhealthcare wrote on Tuesday, May 08, 2012:
This Freeshim seem s to be along the lines that we have envisaged. And it seems to be part of Freemed as well. Need to figure it out. There are a hell of a lot of components to configuring and EMR and I wonder how small practices download this and configure this by themselves. e have a great team in ZH Healthcare yet sometimes the tasks seems daunting.
I have a few clients from the other parts of the world who requires this interface and i have no choice but to move on with this thing. Maybe we will try and get the certification as well. We will see.
Any and all suggestions and guidance is welcome.
Shameem
avantsys wrote on Friday, May 18, 2012:
Funny as it may seem, many doctors we have come in contact with prefer the following policy (as crazy as it may seem):
They use one computer (usually an aging PC) for internet and for working with the Greek state’s e-prescription (which is currently offline for reasons too politically-related to discuss here), e-diagnosis and e-billing websites (yes, we’re talking about **THREE **different, _unrelated _web-based applications, in which the doctor has to manually enter the same data - and, although they claim to be open source, no source code or API has been provided to anyone that is not extremely well-connected to the “right persons in the right places” to facilitate interoperability of EHR software with the state’s applications).
Then, they keep another, usually much older, PC connected to their medical devices. This PC is not connected to the internet and is not connected to anything except the mains power (naturally) and the medical device(s). It’s used for storage of files generated by the medical devices ONLY.
Konstantinos