If you decide to build a new Electronic Medical Record (EMR) System or some other smart tool to make a difference for the clinicians, would you build it up from scratch or would you look around for a ready-made platform to build upon. What if I told you told you there exists just the technology for building that next generation tool of yours? What more, it is free. Don’t believe me? Just read on.
- The said technology has at its heart a well-thought out and clearly documented protocol
- It allows plug and play applications that can be built with relative ease, because of exposed APIs that are easy to understand. Some of these might be automation tools, like agents or even user-assistance tools. So you can build a feature-rich system just by assembling third party gadgets. Suppose you want your coding done at the run time as you type or dictate your clinical notes, you might be able to just “add” such a tool to your application.
- It allows collaboration. This is not your mom’s collaboration (recipes over email), but real time collaboration, not just of text but of other database operations and actions that every other participant can see and modify. One could even think of hundreds of participants working over a common artifact. I daresay, the healthcare reform bill could have been written in 2 weeks if they had used Google Wave. (Not really. Technology can only help this much. Agreeing to agree, agreeing to disagree, disagreeing to agree, waffling, and grand standing would still take as long). The collaboration would not just extend to entry of clinical data (which itself could have multiple authors and sources, the clinicians, paramedical personnel, patient and families, medical devices, etc.) but also metadata and the knowledge artifacts that make such applications truly clinical by changing their behavior based upon current medical knowledge. Imagine, a group of cancer specialists and radiologists collaborating to create new rules for screening for breast-cancer – rules that are executable, not text admonitions. Rules that can be directly executed by the rules-engine of your clinical application to allow advising your next patient, whether she needs mammography or not based upon current research. The collaborations can be changed easily, with participants being included and dropped as easily, as needed, across boundaries of organizations.
- It automatically maintains a record of actions of all participants, so one can tell what data was changed by whom, where and when. This means you can roll-back any actions if you want, you can even rewind and play forward. This also allows keeping an audit trail of clinical activity and makes provenance possible for the knowledge and metadata that is authored by experts to provide the clinical intelligence for the applications.
- It has in-built capabilities for user authentication and data privacy.
- It has federated service architecture, which allows for flexibly linking up networks and for safety of data by redundancy. You may keep your network all to yourself of course, if that is how you like it.
- The specification for the technology is open and free and so is a much of the code for the service and the tools. Anyone can contribute towards improving the protocol and the API specification.
In short, it has much of the infrastructure taken care of so that you need to develop only the interesting stuff. Just a little bit of baking and some icing and you could have killer cakes going around.
I doubt if it is the first thing that comes to your mind, but I am talking of Google Wave of course. (https://wave.google.com/).
I became aware of Google Wave when it was rumored as Google’s next big project, to be released at Google IO 2009. And released it was, with some fanfare. It was received with matching enthusiasm by developers. In the world of technology, new tools are announced every day. Most these days seem to be designed to facilitate teenage banter. Google Wave seemed like one more fun channel to help you make doodles while you chat. I kept checking it on and off and saw it progressively improve. However, I never quite saw its value beyond chatting and working on documents with someone else at the same time. Sure, some of the gadgets and robots that other developers created seemed clever but nothing that would make me log in everyday. Clearly, it was no alternative to email as it was made out to be by Google.
I was prodded into taking another look at Google Wave only recently when the paper by two Googlers, Gaw and Shankar was released. They propose use of Google Wave to create Personal Health Records (PHRs). They emphasize the collaboration capabilities of the Wave technology and how it would allow aggregation of clinical records for a patient from different resources. Spurred by it we had started researching if Google Wave is where we should be building authoring tools for Proteus and GreEd. We were really excited about its potential to provide a platform for collaborative development of executable clinical knowledge.
But soon we got the bad news that Google is pulling the plug on the product and any further development of the technology.
I am not the one to rush in to take up causes. But because you belong in a certain field some causes are given to you and you can’t just turn a blind eye to them. Google Wave is certainly one cause that seems worth fighting for. If enough number of thought leaders and developers make an appeal to Google, they may reverse their decision to kill Google Wave. Thus the campaign “Save the Wave”.
Please click on the following image and express your support.
- The protocol and the APIs are still undergoing development but have already demonstrated their potential by numerous applications that third party developers (individuals and corporations, both large and small) have created
- As far as I know, no auto-coding tool currently exists, but it will not be too difficult to build one on top of Spelly, the semantic spell-check robot that Google’s NLP group has developed.