Posted by: RedaChouffani
mhealth, mHealth applications, mobile health
As we continue to see more health care providers adopt medical records and the push toward coordination of care, many are asking the same, common questions, one of which is: Why can’t these applications just talk to each other? Well, there are definitely several ways to answer this, but the question that needs to be asked here is: Why didn’t EHR providers predict such a need, and agree one way or the other to create some type of standards to ensure interoperability? Could it be that they were competing with each other, and simply did not see the value — even if there is value for the patient here — in exchanging records many many years ago?
Well, this is the reason this question is being asked here. Clearly in the same way that we have seen several EHR vendors in the market place bring innovation, and grow to be very successful software vendors, we will see the same in the mHealth applications of tomorrow. And we can already start seeing a similar disconnect with many of the available apps.
Let’s take the example of a medical application out there that can provide risk assessment that can be developed from heart surgery. The information would generally be stored on the mobile device that the cardiothoracic surgeon uses, or even the cloud but never reported back to the EHR or patient PHI record.
We can also see another example for patients that have had bariatric surgery and are following a specific diet that requires daily logging using some of the apps. But much of the information here such as food intake and exercise logs are kept on the mobile phone as well as the cloud storage for the wellness solution provider. This leaves yet another missing link in the patients overall health record.
This will continue to be more significant as more apps become available and widely used. And as the gap continues to increase, it may be little too late at that point to try to get every mHealth app provider to agree on a new way to share information in a standardize method. As a software developer, part of my mhealth app strategy is to always follow these few rules:
- Develop the mobile solution to be able to store data in the cloud
- Develop server based solutions that can authenticate requests from outside entities through web services or other secure means
- Allow flexibility in what data can be exchanged
- Accept and store information from outside entities (such as patient information during an exchange or transfer)
- Allow for virtual printing of summary of whatever information the mobile app is generating.
While there are most definitely more to this than what was mentioned in, but this can be a good start to attempt to create a framework for mHealth apps that will ensure future interoperability as well as ease the critical exchange of information.