Marcos Athanasoulis, M.P.H., Dr.P.H., Crohnology.MD Technical Director, Healthy Communities Institute
A common hope among non-developers in the e-health and mobile space is that the personal health record (PHR) is the nirvana for keeping all data in one place and enabling a whole host of PHR applications. Although the PHR can do a pretty good job of keeping data in one place, what is often misunderstood is that for developers to do anything useful with a PHR, they inevitably need to have a local copy of that data. And, as soon as an application has its own data, it is a slippery slope to having its own data definitions, data that isn’t shared, and data that gets out of sync with the primary PHR. Until some major barriers are addressed, mobile application developers are faced with real challenges to actually building applications that run directly off of PHR repositories.”
Let’s take a look at the top four barriers to using PHRs as a true backbone for applications:
If you are querying a significant amount of data at once, rather than getting one measurement for one period, it is often not practical to rely on a remote query to database – especially if you want results in anything less than the time it takes to get a cup of coffee down the hall.
2: Network Availability
Most mobile applications cannot count on having a connection to the Internet. If the developer relies on a remote PHR to get their data, and there is no Internet connection, then the developer will not able to provide the user with the data they need. If the developer keeps a local copy, then they can access it with or without a network connection.
3: Tools Availability
Most application development environments are optimized for a standard database backend. Most developers know how to write SQL to fetch data from a database, and they have the tools to readily use that data in an application. Adding a layer of an API call for every piece of data adds a considerable layer of complexity to the development process.
4: Lack of Standards
Even if there were a high performance, distributed PHR that let you write SQL directly against it, which one would you pick? You might have chosen Google Health. But because Google is discontinuing the product, Google Health is no longer a good choice. You could choose Microsoft HealthVault, but you are tying your fortunes to Microsoft. There is not yet a true distributed, open PHR that developers can count on for the next five years – or even the next year.
None of these barriers is insignificant. The Project HealthDesign teams have struck a balance by maintaining local copies of data, but, when possible, pushing data to and pulling data from PHRs like Google Health and Microsoft HealthVault. But until an open architecture for high performance exchange of PHR data is invented and adopted, mobile health applications developers will continue to maintain data locally and use the tools that allow them to build mobile health applications that really help people.