Can the Fun Apps of Web 2.0 World be Useful Apps for the Healthcare World?
Posted by admin in EHR, GreEd, Open Source, Proteus, Web 2.0Many a conference have been organized and quite a few more papers and articles have been written about how Web 2.0 can revolutionize healthcare. The thought leaders have declared that Healthcare 2.0 is here – A new era where the Web 2.0 paradigm influences healthcare. It is said that connectivity between people and crowdsourcing that these new approaches facilitate will deeply influence how providers and consumers exchange information and make decisions.
All of which is true, notwithstanding the fact that the technology to do all that already existed – it’s just that the awareness of its power has reached the tipping point where everyone has started chanting the same mantra, in unison. No doubt these are powerful shifts and will have profound impact on healthcare. But, I have always felt that these cheerleaders have missed something fundamental. There has been so much emphasis on the social networking aspect (fuelled in no small measure by the sheep mentality of the venture capital and angel funds), that the other important aspect that can inspire new things in healthcare has not been given enough attention. That aspect being the component approach that the Web 2.0 has popularized. So many interesting tools have been created by the intrepid developers of Web 2 world that probably many of them can be mashed together to create really useful apps to do things in healthcare which were not easily possible or even conceivable earlier. It is also encouraging to see that so many have been brave enough to allow what they have developed to be used by others in ways which might be quite different than for which they were originally created.
To me there could not be a better open source opportunity than this. Therefore I am surprised by the lack of enthusiasm that the open source champions have shown in taking to this approach (this gripe will get another post in the future – stay tuned).
Here is an example of what is possible: To create a mashup EHR for which very little code, mostly glue code is written, complete with structured data capture, CPOE, PACS, direct data inputs from devices and storage for all of this in a cloud with interoperability to boot.
Let me hold forth for a bit on each of these things.
Data Entry
If you have used Evernote, you will know how easy it is to maintain a stream of data of different kind through it. (If you have not, I suggest you take it for a spin – this alone will be reward enough for you to read this post. It is free, fun and useful.) The data is automatically synchronized across all the machines that have access to the account and can also be accessed on the web too. The API for Evernote is open, which means it will be easy to develop structured data capture templates and order sets, which you execute from your respective machines or smartphones and let Evernote take care of the infrastructure for safeguarding and synchronizing the data. The data could include images and audio.
Data Capture from Devices
Why can’t Eye-Fi be modified as a data capture device to route not just your clinical pictures to online picture archives but also the other kind of data to other archives. I can easily think of a myriad equipment including sonographic and lab devices from which the data be directly routed to an online EHR. I hope the Eye-Fi folks are listening and make its firmware open source. It will do ton of a good to their sales too.
I remember working as an obstetrician in India dealing with high number of high fetal risk pregnancies. The setting itself required us to take the most state of the art concepts and create low-tech adaptations for them to suit our patients, many of whom were not literate. One such adaptation was of the Cardiff “count to ten” card where we would ask the patients to keep a record of their in-utero baby’s kicks. We would have to spend a lot of time explaining how to record the kicks. Only if we had Kickbee Electronic Fetal Monitoring with Twitter in those days! Come to think of it, why can’t we have more of Twitter based monitoring systems. How about my sleep pattern or my blood pressure record as an automatic twitter stream? Let me also remind you, Twitter also provides access to its own API (as yet not explored by me).
Can you think of some other useful ideas for Twitter? How many data elements and their values can be fitted in 140 characters? Feel free to post your responses to this post.
Online PACS
Is it too much of a stretch to think that Flickr and PicasaWeb (and many other similar services) cannot be converted into PACS. Even if they do not contain all images in their highest of resolution much useful visual data can be stored in these archives. Need I say, the APIs to both these services are also exposed, begging to be glued into some healthcare apps?
Cloud Storage with Interoperability
And finally, the cloud storage which, despite the name, is actually much less nebulous than the interoperability issue that is tagged to it here.
Google Health and Microsoft HealthVault have ushered in a new era, the impact of which will be far reaching. I do believe that most pundits have failed to grasp the import of this phenomenon (subject of yet another post, in future). But for now, let me just say that these can easily serve as the final destination of all data that is collected by the approaches described above.
Indeed, these modern day PHRs are increasingly emphasizing ease of connectivity with devices, which means you can directly upload records of your BP, Blood Sugar, weight and exercise records from compatible devices. This means, that we may not even need to torture Twitter as suggested above.
They also provide a simplistic approach to interoperability by sticking to standards like CCR and CDA. Google Health API and HealthVault SDK and API are well documented.
Proteus in the Web 2 Health Amalgam?
You might well ask me this question at this stage: “And, what is your axe to grind in this potpourri grinder that we will build, pray tell?”
And I might come back with a question of my own – Tell me what is missing in most modern day EHRs?
IT IS THE PROCESS, STUPID!
So my axe in this new EHR, if we dare to build it, is process representation using Proteus.
Proteus is a way of representing processes, including those of healthcare. The processes are built in Proteus not by using throwaway, one-time-use actions and events, but by reusable entities that themselves are processes or activities. So as you create a process you are also incrementing a library for future use.
As some of you already know, Proteus and GreEd are to be made available under an open source license. Our team at the Henry Ford Health System (nothing to do with the beleaguered Henry Ford Auto company), is developing Proteus to allow it to work interoperably with any EHR. Proteus will not just provide process representation but also a way to infuse those processes with intelligence thus providing clinical decision support.
Indeed, what we are doing in our project, called the Semantic Data Capture Initiative, is laying down the foundation of a new kind of EHR, which will be a process oriented EHR, quite unlike other EHRs available currently. So different will it be in its capabilities from the traditional EHRs that we may even call it XHR or XMR – Extreme Health Record or Extreme Medical Record systems (more about this in a future post).
- Read more about Proteus here: http://www.proteme.org/
- Find out something about GreEd from the presentation I recently made: http://www.proteme.org/presentations/greed3.pps
In Conclusion …
Please note this is not intended to be a recipe for the next generation EHR but just to stimulate you into thinking about a mashup approach for building healthcare related apps. Also I have not listed many other ingredients which might as well find their way into the recipe
We have all the ingredients to slap together into a newer and smarter EHR. Will the open source guys step up to the plate please. For that matter even a start up company can quickly create this next generation EHR with little investment.
I look forward to your comments.
Entries (RSS)