NAHIT "Defining Key Health Information Technology Terms"

NAHIT recently released a document called (get this):

The National Alliance for Health Information Technology Report to the Office of the National Coordinator for Health Information Technology on Defining Key Health Information Technology Terms

Basically, it has some interesting definitions for some common healthcare terminology. The location of the original document (along with the rest of the NAHIT site) appears to be down at the moment, but John Mertz at NeoTools has conveniently listed the terms for us, so I'll repeat them here:

• Electronic Medical Record: An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one healthcare organization.
• Electronic Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one healthcare organization.
• Personal Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.
• Health Information Exchange: The electronic movement of health-related information among organizations according to nationally recognized standards.
• Health Information Organization: An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards.
• Regional Health Information Organization: A health information organization that brings together health care stakeholders within a defined geographic area and governs health information exchange among them for the purpose of improving health and care in that community.

I don't know whether there is industry-wide agreement on these definitions, but they're an interesting start for the uninitiated.

Microsoft HealthVault and Google Health

Long-time rivals Microsoft and Google have found something (relatively) new to bicker about: Internet-based personal health records (PHR).

Microsoft HealthVault and Google Health aren't the first PHRs on the block. Existing players include AllOne Mobile, Revolution Health, and dozens of others (see myPHR.com for a lengthy, but still incomplete, list).

In a way, HealthVault and Google Health aren't really PHRs at all, but rather platforms that PHRs can be built upon, or used to aggregate data. Microsoft, in particular, insisted at their recent HealthVault Summit that they don't intend to compete with Google Health, but rather to seek opportunities to integrate with it.

So, where are these guys going with this?

Microsoft HealthVault
Microsoft has had a great deal of success pushing their products through their partners, particularly ISVs. For example, we've benefited in the past from the fact that not only do we use Microsoft servers in our data center, but we also require the use of Microsoft Word for certain functions within AdvancedMD. Microsoft appreciates that, obviously, and helps us out with software licensing and co-marketing opportunities.

In the case of HealthVault, Microsoft hosts an annual HealthVault Solutions Conference where participants "hear directly from healthcare professionals, consumers, and Microsoft product managers to better understand the overall health landscape and product roadmap."

At the most recent conference, 40 vendors demonstrated products that they are building to interact with HealthVault.

Microsoft also announced that they would be awarding $4.5 million in grants to support organizations that are developing applications that are using the HealthVault platform.

Working through partners may help Microsoft overcome a lack of trust that the public has in the company to protect sensitive information, partially due to the highly-publicized security holes in Microsoft Passport.

Of particular interest is Kaiser Permanente's pilot program to provide health information to its nearly 160,000 employees using HealthVault. If the pilot is successful, it is likely that the program will extend to all of Kaiser's 2 million+ members.

Google Health
For its part, Google Health seems to be pursuing the consumer market more aggressively, which makes sense given its huge popularity and trust among everyone from 16 year-old script kiddies to 90 year-old grandmothers.

Even so, it seems reasonable to assume that Google will rely just as heavily on participation from partners (including Microsoft?) to achieve success, as a report from IDC suggests.

Blue Cross and Blue Shield of Massachusetts recently announced that they will be providing their members with a mechanism to import claims data into their Google Health accounts, via their consumer health portal. The integration should be completed before the end of the year.

For a very interesting inside look at Google Health, check out this post by Robert Wachter, a contributor to The Health Care Blog. Fellow contributor Matthew Holt posted this in-depth test drive, also very useful.

So, is this healthcare's 21st century version of the battle between Beta and VHS? (For our younger readers, consider the fight between HD-DVD and Blu-Ray.) Or can the two behemoths coexist?

It's hard to say. As a Microsoft Gold Partner, it is likely that we'll look most closely at HealthVault first. Ultimately, we (and other ISVs and health plans) will need to integrate with both. And they'll need to make nice and integrate with each other.

Why SaaS? Agility

Ken Meyers, our VP of Operations, recently reported the following statistics:

1. Industry news reports (http://www.modernhealthcare.com/, among others) identified a 4x or more increase in rejections around national claim flow.
2. Emdeon is reporting 25% Medicare and Medicaid rejections persisting 1 week after the deadline.
3. Mysis reported to their customers a 50% increase in call volume after the deadline and asked for patience.
4. Regional medicare centers are experiencing major spikes in call volumes (http://www.wpsmedicare.com/, among others)
   ...
5. AdvancedMD experienced a daily call average DECREASE of 4.4% the week after the deadline (including accounting for Memorial Day), and we do not have any information indicating any material increases in rejections from RelayHealth.

So, why do I post this on an architecture blog? It all comes down to the agility that is inherent (or should be, if you're doing it right) in the SaaS model.

Most of our competitors are either Neanderthals (defined here as locally-installed client-server systems) or dinosaurs (text-based systems running on, for example, DOS or AS400s). When CMS announced the dearly beloved NPI requirements (described in boring detail here), most of those guys didn't just have to rush to modify a bunch of code to meet the requirements. They also had to figure out how to get their updates deployed to all of their sites...thousands of sites in some cases. And that assumes that their customers were willing to pay the (sometimes exorbitant) fees for the upgrade.

Once they had the upgrades installed in (most?) of their customer sites, they had to wait for the feedback on why their upgrades aren't working. Then fix the updates, deploy them, and wait for feedback again...and so on.

For AdvancedMD users, the NPI requirement has been, I have to confess, not particularly easy. No major changes in healthcare come without a few skinned knees. But glitches were found and then corrected quickly and, for the most part, transparently, on a weekly basis. By the time May 23rd rolled around, we were ready to go. Our customers even have a handy link to the NPPES NPI Registry so that they can quickly find NPI numbers for their referring providers.

With healthcare regulatory changes being as frequent and confusing as they are, a SaaS technology and business model just makes sense. And it keeps our customers laughing all the way to the bank.*

*Not really...I would imagine that most have ACH and don't physically deposit their Medicare checks. But you get the point.