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.

SQL2008: Solving the file system vs. database BLOB quandary

I found a recent post on The Data Platform Insider blog very interesting:

One of the most exciting new features in SQL Server 2008 is the ability to store files and BLOBs directly in the file system, while maintaining transactional consistency with a SQL Server 2008 database. SQL Server 2008’s new FILESTREAM attribute for VARBINARY data type solves the age old dilemma facing developers and IT Pros: Is it better to store files directly in a database or store them in the file system with path and filenames stored back in tables to maintain the relationship with the database?

We've been fighting with this for years, for all of the reasons cited in the blog posting.

It doesn't solve one big problem, though: Some of our customers have multiple gigabytes of images and documents each. Add that to half a gig or more of transactional data, and then multiply that by a few hundred customer databases, and you've got a real challenge storing and moving database backups around.

To paraphrase (and, apparently, misquote) Senator Everett Dirkson, "A terabyte here, a terabyte there, and pretty soon you're talking a lot of data."

An oldie but a goodie: How the customer explained it...

I just walked by Steve Burke's desk (he's our Manager of Data Conversions and Imports, or something like that), and noticed a great cartoon that describes the challenges of communicating and faithfully executing customer requirements far better than I have in previous posts. It's been floating around for a few years, but it's pretty clever.

It addresses both the argument for UI-first development and the need for a bridge (in the form of Chief Architect, in our case) between Product Management and Engineering.

Unfortunately, I have searched but have been unable to find out who the author of the cartoon is, so I can't give credit for it. If anyone knows, please submit a comment and I'll add an acknowledgment.

(Click the thumbnail to see the full-sized image.)

The NPI debacle in layman's terms

[Disclaimer: You probably don't want to read this. It's dry and boring. I dozed off twice while writing it. It may not even be all that accurate. Plus, you can get the same information from this CMS FAQ.

But they say that the best way to learn is to teach. So, as I struggle to understand how we got into the mess that we're in with NPIs, perhaps the best thing I can do is to try to explain it here.

So, go ahead and read if you like...but don't say I didn't warn you...]

What is the NPI?

The NPI (National Provider Identifier) is a 10-digit number used to identify healthcare providers. (A "healthcare provider"can be an individual person, as in the case of a physician or nurse; or a group of individuals that submit claims to certain insurance carriers as a single business entity.)

The NPI was mandated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA). (Standard unique identifiers are required for both healthcare providers and health plans, but the identifiers for health plans have not yet been implemented.)

What does the NPI replace?

Historically, different insurance carriers have used a variety of different numbers to identify providers. Medicare, for example, used to issue its own proprietary identifiers (PIN, UPIN, OSCAR, NSC). Many Medicaid payers and most commercial payers expected the provider's EIN (Employer Identification Number, also known as Federal Tax ID). Still others required the provider's Social Security Number.

To further complicate the issue, some payers may require multiple identifiers. Others may give providers a choice of enrolling under, say, their EIN or their SSN.

What problems is the NPI supposed to solve?

All of the healthcare providers and insurance carriers in the United States are part of one ecosystem, with many millions of paper and electronic transactions taking place between the various parties every day. It shouldn't be a surprise to anyone that multiple provider identifiers would cause confusion and inefficiency.

One example: Primary claims submitted to Medicare, after being adjudicated by Medicare, are automatically forwarded on to the secondary payer (if there is one). Medicare can use the PIN to identify the provider, but the provider's Medicare PIN means nothing to, say, Medicaid or Aetna. So, in order for the claim to be forwarded to and paid by the secondary payer, the provider must include the EIN...or SSN...or the secondary payer's propietary identifier...or whatever, on the claim.

The NPI only addresses these issues if all providers and carriers switch from whatever identifiers they used in the past to the NPI. Consequently, all HIPAA covered entities (providers, payers, and clearinghouses) will be required to switch.

Who issues NPIs to providers?

The Centers for Medicare and Medicaid Service (CMS) issues NPIs using the National Plan and Provider Enumeration System (NPPES). (NPPES can also be used to look up NPIs.)

Can a single physician or other provider have more than one NPI?

Allowing a single healthcare provider to have more than a single NPI would violate the HIPAA requirement that NPIs uniquely identify a single provider. But this is healthcare we're talking about, so I wouldn't be surprised if it happens.

So, once a provider has an NPI, how do payers find out what it is?

As part of CMS's planning for the NPI transition, they conceived the notion of a "crosswalk" (a commonly-used term in healthcare that has been overloaded for this purpose). Basically, payers are expected to accept both their legacy identifiers and the NPI for a period of time, during which they are supposed to "crosswalk" the identifiers and associate the NPI with the corresponding providers.

On May 23, 2008, this crosswalk period officially ends, and all payers are supposed to accept claims with only the NPI. Of course, again, this is healthcare, so some payers (and we don't know how many) will fail to meet that deadline, or their systems will be so whacked that they will continue to reject claims until they can get their software fixed.

No apologies: The reality of technical debt

I attended an Agile roundtable this evening, and one of the sponsors, Jonathan Rayback (an Agile thought leader in the Salt Lake City area) introduced me to the concept of "technical debt". It's been around for a long time (at least since 1992), so I'm late to the party, but the idea really resonates with me.

The term was apparently introduced by Ward Cunningham, and has been expanded upon and clarified by Steve McConnell, among others.

Here's the definition supplied by the venerable (but oft maligned) Wikipedia (hyperlinks removed):

Technical debt is a term coined by Ward Cunningham to describe a situation where the architecture of a large software system is designed and developed too hastily.

No one who has been developing software professionally for more than 5 minutes has been able to avoid technical debt.

Jonathan illustrated the idea with a whiteboard graph that looked something like this:

In this chart, the project was expected to be completed in about 20 days. About 13 days into the project, it became clear that an additional 4-5 days would be required to complete it in a high-quality way. However, a business decision was made to stick to the original schedule by working more hours, cutting corners, or making some other compromise.

The area between the red line (the business-mandated schedule) and the green line (the "ideal" schedule, for the sake of quality) represents the business debt incurred during the course of the product.

Like financial debt, technical debt must be repaid at some point. And, like financial debt, not only the original principal will need to be repaid (in the form of refactoring, bug fixes, etc.), but also accrued interest (customer complaints, support calls, etc.)

To advance the metaphor further, Jonathan pointed out that not all technical debt is bad.

Most of us who own homes owe a sizable financial debt in the form of a mortgage. Did I make a mistake by going into debt to own my home? Certainly not: I estimate that my family's housing expenses over the past 11 years have been far less than they would have been if we had been renting during that time, even if we had lived in a much smaller home. It would have been ridiculous to wait to buy a home until we had saved up enough money to pay for one.

In the early stages of developing our software and service offerings at AdvancedMD, we incurred huge technical debt. We've had good-natured debates about whether that was a mistake or not. On the one hand, our coding and deployment efficiency is lessened by shortcuts we've taken in the past. On the other hand, we were first to market with a web-native PMS (by years), and we remain light years ahead of our nearest competition.

We've also made great strides towards paying off that debt (and minimized the accumulation of new debt as much as possible). We've rearchitected major components of our application over the years, so that, as a whole, I'd put our code up against just about anyone's. Sure, it would have been great if we hadn't had to do that rework, but, again, in most cases the debt was justified.

Not all technical debt is created equal. Here's how Steve McConnell categorizes technical debt:

Non Debt
Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.

Debt
I. Debt incurred unintentionally due to low quality work
II. Debt incurred intentionally
II.A. Short-term debt, usually incurred reactively, for tactical reasons
II.A.1. Individually identifiable shortcuts (like a car loan)
II.A.2. Numerous tiny shortcuts (like credit card debt)
II.B. Long-term debt, usually incurred proactively, for strategic reasons

Only debt in Category I should be a source of embarassment...and, yes, we have our share of that kind of debt, although far less than a few years ago.

I make no apologies for the other types of technical debt that we've accrued, because we've overcome the odds by proving both our technology model (which, in 1999, was utterly original) and our business model.