Part III: Understanding how to Develop Applications with HealthVault

Microsoft's HealthVault is not a "PHR" but rather a "PHR platform" with a set of back-end services for secure storage, retrieval and sharing of healthcare information. These services can be used by a developer to actually build what we may describe as a "classic PHR".

What does HealtVautlt mean to me as a developer? How does it work?
Here is the scenario as I see it, which explains how a developer may start to think of ways to use HealthVault:

Developing with HealthVault
- Lets assume a patient, John Doe registers for a HealthVault account. This is where his healthcare data would be stored. John Doe controls access to this data using his "Windows Live ID" credentials (user-name and password).

- Now suppose, I as a developer create a new PHR product called "Acme PHR" using HealthVault on the backend. That is, I develop the presentation layer, the actual website with my company's logo etc. I decide the look and feel of the application and the type of data I want want to collect and store for a patient. Additionally, I would also develop the business layer containing the business rules, knowledge-base and decision support functionality.

The final Acme PHR product is my company's application. The application performs the functions that I want it to perform. I can do interesting things with the application by combining the data in HealthVault with additional data that I define and store separately on my own server/database.

Designing a new HealthVault-based application- Personal Diet Planner and PHR
What do I mean by combining HealthVault data with my own defined data? Lets take an example. Suppose I want my PHR application to have the ability to provide different diets for patients with various health conditions, like diabetes, hypertension or obesity.

With my PHR, I will want to collect patient data such as weight, blood pressure, health conditions, blood sugar values, cholesterol results etc. This data is patient specific, so I decide to use HealthVault as the storage mechanism. Besides the convenience of using HealthVault's APIs, the big advantage of HealthVault is that it handles all the security issues, such as authorization and role based access to data (specified by the patient).

The database of the different diet plans however is stored on my company's servers. It is my company's proprietary data and would be kept entirely separate from HealthVault's data.

With my application, I can combine patient specific data from HealthVault, with my database of diet plans. So if a patient using my PHR, has high blood pressure and is obese, I may recommend a particular diet plan, while someone with just mild obesity, may get another diet recommendation. This is my application's "secret sauce", the ability to decide the proper diet for specific health conditions.

This is an important point, because my application is not about the details of storage and retrieval of health data, but rather, on how I use this patient's specific data and combine it with other data to create new innovative personal healthcare applications. This is much like an operating system. HealthVault essentially acts as an operating system like Windows, handling all the low level detail and chores, while my application focuses on the big picture.

Whats next? More Applications using common HealthVault Data
So patient John Doe uses my "Acme PHR" (with the special diet plan feature), and has entered his health data. John Doe is very happy with my PHR product.
But now, another company creates another product using HealthVault which recommends exercise plans for patients with specific health conditions. John Doe likes this idea. He has all his data already entered via my PHR product and is happy with the diet plan. He now wants exercise recommendations. John Doe can subscribe to this new "Exercise Planner" application. Fortunately, because it too uses HealthVault, John's data is already entered. This data can now be used by this new application. So using John Doe's existing weight, blood pressure and health condition data, an exercise plan can be recommended by this new product. There can be other products which do other things. The possibilities are endless.

HealthVault is like an Operating System
You can see the tremendous advantage of having personal health data stored once, with the ability to use it in multiple ways with disparate products. Just as the Windows operating system has resulted in countless software products, HealthVault likewise may lead to countless health care applications.

PHRs, too much Hype?

HIStalk's comments on HealthVault were very insightful as usual. I think the industry is a little too high on the concept of PHR. As HISTalk hinted, I do doubt most patients want to manage the details of their own health records. Much the same way that most of us would rather have Fidelity manage our 401Ks than having to try controlling every fund and stock within the account ourselves. That being said, under the right circumstances, I believe a PHR can complement a physicians own record keeping.

Part II. Microsoft's new HealthValult, More thoughts

I had more time to look at Microsoft's HealthVault. As I mentioned in my last post, after creating my own personal account, I was disappointed by the sparseness of what I saw. There was no place for me to enter my past medical history, medication lists or allergies. As a physician and a software developer, I must admit, I was confused by what I saw. It was not entirely obvious from the look and feel as to what the application really does.

I was hoping for a robust PHR. In fact, I was hoping to start signing up my patients for accounts as they presented for their appointments. However, if I found the application confusing, it would be pointless trying enroll my patients at this point.

I looked up all the available information on HealthVault from the Microsoft site. Because of my experience in developing healthcare applications, I believe I have a fair understanding of this application now. However, for many, I believe the application is a bit obtuse. I think it's fair to say, HealthVault, despite a barrage of news in the popular media, is not quite ready for direct patient use.

I do remain excited by this offering despite my early disappointment. Having a large company like Microsoft leading this effort, I believe there will be more opportunities for independent developers to create new healthcare applications. I know many think Microsoft is trying to "take over" healthcare, but I'm trying to take the positive view. We'll just have to wait and see.

More on HealthVault later...

Microsoft's new Health Valult, a PHR?

I received notification about this new offering by Microsoft, "Health Vault". Dr Crounse, Worldwide Health Director for the Microsoft, writes about it in his blog.

As a practicing physician, I'm really excited about this application and have signed up for a personal account. My plan is to start enrolling my patients with the hope of consolidating their medical data.

I found however that the application did not have a place for me to enter my past medical history, medication lists etc. I think, for this application to work for my patients, this feature needs to be in place. Perhaps this feature already exists. If this is the case, it needs to be more obvious to the user. I know this is in beta, so I'm willing to wait. My hope is that the Health Vault is a true PHR.

There is an interesting integration feature. I can fax documents to my patient's account using a fax subscription service that converts the faxed document to a PDF file for storage in the patient's Health Vault. The patient must subscribe to the service. The cost is very reasonable however.

I will write more about the HealthVault as I discover more of its features.

Results Managemenent, Critical results reporting

Clinical test reporting is a big issue for physicians. As a physician based in an ambulatory office, I may have several patients at any given time undergoing various radiology tests such as a chest x-rays or CT scans. When the results are normal, it's okay to receive the results by routine fax or ground mail. Potential problems however occur when there's an abnormal result that needs follow-up.

Although many times these critical results are also faxed to the doctor, this really is not an acceptable way of communicating a result needing follow-up. Faxes are notoriously problematic. You can never be sure that the recipient has received the faxed document. After all, fax machines can run out of paper or ink and there is no way for the sender to know that the recipient has received the document.

There needs to be proper follow-up on abnormal test results. By this I mean the radiologist making the abnormal finding should really be calling the ordering physician to review these abnormal findings and to develop a follow-up plan. When results are very high in critical severity, this process usually occurs. When the results may not rank high in the severity scale but are still abnormal, a one-to-one notification method still needs to be in place. There needs to be a system to verify that the abnormal result was received by the appropriate party. An electronic system would be ideal.

If an abnormal result has not been receieved by the appropriate provider, another attempt must take place to convey the results. If all attempts fail, there needs to be further escalation of the process to ensure that a responsible physician is able to act on the abnormal results.

I came across a possible vendor solution to this problem:

"Critical test reporting, closing the loop"

http://www.vocada.com/veriphy-solution.asp

Learning from Past HIE / RHIO Mistakes

I just received an eHealth SmartBrief which contained a great editorial from Health Data Management, "Learning From Mistakes" which discusses how we must learn from mistakes of past HIE and RHIOs. The author highlight several points that I also have been making. This did not surprise me when I read that the author, too, like my self, is a practicing physician dealing with the day-to-day chores of clinical data management,
Here a few quotes from the article:

"pioneers in this emerging field concentrated on creating entities, not functionality. " "... they set out to build an organization like a RHIO, rather than advance the attainment of information exchange. "

I have been commenting on this point of how RHIO have been all about setting up large organizations rather then entities that actually do something useful from the physician user perspective.

Another great line from the article:
"With the focus on form, not function, it was easy for participants to get sidetracked with political agendas, competing priorities and administrative processes..."

This reminded me about a recent encounter at a healthcare conference recently, where I met the head of a major EMR vendor's community based initiatives group. While discussing our RHIO initiative, SEMRHIO, I was asked by this vendor representative,"What is your governance model". I smiled and told her, " Our model is about creating real value for the physician , not about by building an organizational structure".

I believe in the "If you build it, they will come" model. Like any great invention, its the idea that comes first, then the organization. After all, Thomas Edison's light bulb came before General Electric.

With RHIOs, we need to focus on "what do our physicians need to enable them to care for their patients?". This should be the guiding principle. It usually takes several iterations to get the right model. Too many development initiatives get locked into a model from the start. RHIOs need to be agile, and have the ability to change or modify the model if required. By having something people really want, the rest should come easy.

Physician Mobile Device Applications

Anne Zieger, editor of FierceHealthIT, writes in her recent editorial, "Physician mobile device use: It's your move", about the need to develop a suite of mobile applications that serves the needs of physician physicians. Because physicians are always on the go, the mobile device, I believe is ideally suited to a physician's workflow needs.

The problem however is the fact the physicians also need to access a vast array of detailed data when taking care of patients. The challenge with these applications has been with making the data easily accessible on a small mobile device and to do it in an efficient manner so as not to be awkward to use.

There are several very useful applications currently available for the mobile device. The Epocrates (http://www.epocrates.com/) drug data base is probably the most popular application designed for the mobile platform. As a physician, I always have it on me and constantly use it all day long.

Another application, that I feel will be very successful, is the mobile platform for medical education/CME/Case consults by QuantiaMD . What I like about this application, is that as a busy physician on the go, I can listen and watch interesting medical content by Quantia on my Motorola Q-phone. This content can be tailored by Quantia to come from my affiliated hospitals, such as hospital grand rounds. Physicians from my healthcare community can post interesting cases and do short powerpoint presentations which I can access on my mobile device or via the web.

I'd be interested in hearing about other mobile applications.