Healthcare Software

A Standard within a Standard: The Continuity of Care Record

Looking at the different implementations of the Continuity of Care Record (CCR) by Google Health and Microsoft HealthVault, I noticed something interesting. I found that despite conforming to a standard, they are both creating dependencies on their particular implementation of it. I think the best way to explain this is with an example. Consider the special rules for each governing the Medications section:

Google Health - Medications Mapping:

• Medications/Medication/DateTime/Type/Text should be set to Start date
• Medications/Medication/DateTime/Type/Text should be set to Stop date
• Medications/Medication/DateTime/Type/Text should be set to Prescription date
• Medications/Medication/Source/Actor/ActorRole/Text should be set to Prescribing clinician
• Medications/Medication/FulfillmentHistory/Fulfillment/DateTime/Type/Text should be set to Dispense date
• Medications/Medication/FulfillmentHistory/Fulfillment/IDs/ID/Type/Text should be set to Prescription ID

Microsoft HealthVault - CCR Mapping (scroll down for Medications section):

• Medications/Medication/Directions/Direction/Indication/InternalCCRLink/LinkID (Must link to Problem)
• Medications/Medication/DateTime (Must be "Administration Date")
• Medications/Medication/DateTime (Must be "Prescription Date")

I think if there is to be real interoperability in healthcare, these issues need to be resolved with consistency. For example, if a CCR record from Google Health is to be loadable into Microsoft HealthVault then the text associated with the Medications/Medication/DateTime/Type/Text element needs to be consistent. It should either be “Administration Date” or “Start date” as having both out there does not allow a CCR to be exported from one solution and imported into the other without requiring some kind of conversion.

Does Microsoft Healthvault Support CCD?

The notion of support is open to interpretation. Many vendors can claim “support” but is this really the case? In this post, I take a look at Microsoft Healthvault’s support for HL7 Continuity of Care Document (CCD).

Microsoft has apparently pushed the envelope in having support for CCD in Healthvault, but just how deep does it go? From what I see it:

Supports:

• Manual and programmatic add of a CCD document to health info
• Limited manual add of items from a CCD document to health info

Does Not Support:

• Programmatic import of health items sourced from a CCD document
• Export discrete data item to CCD format so other systems can read

According to Microsoft on its implementation:

This is a simple form of support for these data types. Some partners have requested the ability to create a CCR/CCD from individual data items in HealthVault, or to break a CCR/CCD into individual items and store those items in HealthVault. We understand the utility of that scenario, but haven't announced any plans about supporting that.

From the looks of it, Healthvault has some manner of support for CCD and it may be sufficient for a lot of people’s needs out there. However, its apparent lack of an export facility hurts the push for healthcare interoperability. A healthcare provider would have to use the HealthVault libraries in order to pull and push data to HealthVault rather than relying on a standard document format and interface. By not having a mechanism to pull data in CCD format forces everyone to support at least two formats when we should be trying to make things simpler.

The Gears of Healthcare

The healthcare industry works a lot like the agile software development cycle. Each morning doctors and residents meet to discuss what happened yesterday and agree on a strategy for each case for the day. The next day the cycle repeats with possibly different staff and different patients. As a result, healthcare is very process driven. It needs the structure to be able to maintain synchronization between all the people all playing their different and independent roles.

Software written for the healthcare domain has to respect these processes. If it doesn’t, it will be difficult to use and get rejected. One mistake often made, however, is the assumption that the processes are linear in nature, much like the waterfall software development cycle. For example, the patient visits admissions, then goes off to receive treatment and then gets discharged, without ever having to move back to an earlier stage.

Human factors in medical devices

The FDA  requires that if you are developing a medical device that you pay attention to human factors and usability in the design. I recently attended a BayBio event where a panel of medical device firms talked about how they meet the FDA's human factors requirement and what impact it has on their product development process. The great news is that, at least for the companies on the panel, they already see usability and human factors as critical to the success of their product. For the FDA, human factors is a patient safety issue, and they are right. Poorly designed devices lead to operator error, which can put the patient at risk or result in misdiagnosis. The panel agreed, but they also use design to differentiate - they know that if they can design a product that offers the best user experience in their segment, then chances are they will dominate their field. This is especially true of new devices and startups looking to displace an established competitor.

One of the most encouraging stories was from Greg Kapust, CEO of Breathe Technologies. Breathe develops a ventilation device, and they require their staff to actually spend time living with a ventiation device. What an amazing way to develop empathy for your customer. We all know that one of the barriers to adopting user-centered design principles is that designers and developers think they know what's best for the customer. Walk a mile in your customers shoes sometime.