Irrespective of national health care policy reform legislation, the medical sector is going full-steam-ahead HITECH

While I've continued to closely follow the dismaying -- albeit admittedly "realpolitik" -- end-game developments in the increasingly acrimonious "health care reform" national political debate since I quit blogging about it in November, 2009 (with snide demagogues now largely in charge of national discourse on the topic), I'd intended to move on next to "drought and western states water policy," regarding which I've culled a ton of technical information and have some arguably value-adding ideas to proffer.

However, I've just been re-hired by my former employer (the not-for-profit Utah-Nevada Medicare QIO) as a Project Coordinator for Health Information Technology (HIT) in the wake of their being awarded the HHS contract to become one of the CMS "Regional Extension Centers" (RECs) under Title XIII of the 2009 Obama Stimulus legislation, ARRA ("American Recovery and Reinvestment Act"), i.e., the ARRA "HITECH" Act ("Health Information Technology for Economic and Clinical Health").

So, bear with me. This is important stuff. Indulge me this coda. It bears to a significant degree on national health policy broadly going forward, given the undeniable importance of timely, appropriately available health data as a core component of effective care. And, the first round of this particular initiative has now been launched and will go forward for at least the next four years** independently of the outcome the current contentious national health insurance reform legislation heading for its final House and Senate showdowns.

(** Assuming the Republicans don't regain control of Congress via this year's mid-terms and thereafter see fit to cripple or asphyxiate the HITECH program.)

"HITECH" - HEALTH INFORMATION TECHNOLOGY
FOR ECONOMIC AND CLINICAL HEALTH

The HITECH goals are to [1] facilitate widespread adoption of electronic medical records systems across the nation (given that health care providers still lag far behind the rest of commerce in the use of digital information technology), [2] guide clinics and hospitals toward using the systems fully, in a "patient-centered" manner (known as "meaningful use"), and [3] assist with the deployment of widespread appropriate, secure sharing of electronic health information through which to improve personal and public health.

ANALOGY

Cheryl, Nick, and I went to to the UK and France in 2004 for 16 days, mainly to go see Lance Armstrong win le Tour #6 in Paris. Which he gloriously did.

I booked and paid for the airfare, hotels, B&Bs, and EurRail passes in advance online. Without adverse incident. I used my credit union debit card multiple times while in the EU, for cash, car rentals, and restaurant meals, etc. All without incident.

Ongoing, like most of you, I routinely buy books and other products from Amazon.com and myriad other mainstream eCommerce sites. Without incident. I increasingly do most of my banking online, including most of my bill paying. Securely, without incident.

I bought my late cat Max's insulin and ancillary diabetic feline supplies online via PetMeds.com (he had a better health plan than do I, LOL). Without incident.

And so forth. You know precisely what I'm talking about. Simply put, absent being "wired" across myriad domains, civilization could simply no longer function. To close the loop on this analogy, the fact that health care continues to operate largely on paper simply means that it cannot function effectively. At root, health care is about making frequently maddeningly complex decisions -- usually under intense time pressure --, based on the best and most comprehensive available information. Most clinicians today still frequently lack such fingertip access.

OK, TO BE FAIR, I'VE INDEED SUFFERED AN INCIDENT

It was relatively banal. We awoke one morning in December 2007 to find that someone had commenced a wild holiday shopping spree in Paris via our credit union debit card. It had nothing to do with our prior EU trip, but, rather owed to my a couple of years thereafter having bought a pair of shoes in Henderson, NV at the DSW "Discount Shoe Warehouse." They subsequently got hacked, with my card number acquired amid the aggregate ePirate booty.

The credit union's fraud indemnity insurance covered the bogus $600+ accruing charges, and shut the card down forthwith, promptly issuing us new ones. Without further problems.

HACKING YOUR ONLINE MEDICAL RECORDS

In the 2009 survey summary depicted above, ~3/4 of the respondents (76%) recently expressed it to be "somewhat likely" (35%) to "very likely" (41%) that "an unauthorized person would get access to your medical records" were they to go digital and subsequently become accessible "online."

Well, while that's probably a rational concern to a point, having worked in credit card risk management (where the fraudster probers were/are 24/7 relentless and insidiously ingenious), I would observe that the Bad Guys are far, far more interested in getting directly into your financial accounts -- for what ought be obvious reasons. Yet most of us engage in a gamut of online financial transactions routinely, absent major widespread adverse consequence.
___

HIT concerns

There are basically three levels of present and emergent online HIT concern. First, even in the circumstance where a particular medical practice's electronic records system (the EMR, a.k.a. EHR -- or, even simply a front/back office non-clinical "Practice Management system") may be confined totally in-house, it remains -- just like your internet account at home -- vulnerable to hacking should there exist an internet connection up and running amid the onsite network, even if not in any way directly interfaced with the clinical system.

Second, if a clinic opts to contract with an internet EMR "hosted service" -- a.k.a. the "ASP" or Application Service Provider model, wherein the practice simply avails itself of the web browser-based input/output screen array comprising the remote EMR, with transactional data being stored on and pulled from "secure" offsite servers, one still must address, among other risks (such as 'net outages), possible encryption-surmounting hacker vulnerability concerns (an endlessly moving target, that).

Finally, we come to the mostly nascent "HIEs" -- Health Information Exchanges (existing today in wildly varying degrees of planning or operational maturity, and comprising the bigger-picture end goal of the REC effort). The national goals here are twofold: [1] enabling patients to accord health care providers of any stripe authorized access to pertinent elements of their clinical histories anywhere/anytime as either exigent/acute or routine needs dictate, and; [2] the "blinded" reporting of clinical information of interest and need to various medical authorities, both for public health surveillance and outcomes research.

The "HIE"

a.k.a, the "Regional Health Information Organization (RHIO)." As I mused in my prior post:

"A fully integrated, electronic health information exchange is essential to ensuring that high-value health care is delivered to the right patient, at the right time, and in the right setting." Yes, of course... These things go the acronym "RHIO" or "RHIE" ("Regional Health Information Organization/Exchange"). The Utah Health Information Network (UHIN) stands as a fairly mature example here. During my last QIO tenure, I sat on the Steering Committee for a southern Nevada RHIO startup attempt. I recall the fractiousness of the proceedings, given the disparate interests of the various for-profit and non-profit interests. We still don't have one in Nevada. I applaud these efforts, but they remain fraught with technical and policy difficulties...

That was several years ago. It does not appear that all that much has changed. The technical (e.g., "data mapping" standards for seamless "interoperability") and policy challenges (e.g., data security, HIPAA privacy compliance) remain many and complex.

I continue to be concerned with the sometimes contentious, duplicative attributes of much of this HIE thinking and effort (i.e., primarily the potentially heterogeneous "regional" aspect).

And, that drives me back to ruminating on my bank risk management days.

THE BUREAU PULL

During my credit card bank risk department tenure, I was involved with vetting applicants for appropriate risk-assessed revolving credit line assignments, and for passing judgment on existing customers' requests for "CLIs" -- credit line increases (or a variety of account forebearances), the latter based on a mix of their current FICO scores and internal account performance histories.

Like any credit grantor, we had essentially instant authorized access to the financial "health histories" of both prospective and existing customers. The first step in consideration of an initial or secondary credit request was the "hard pull" (a.k.a. "bureau pull") from one or more of the three credit reporting agencies: Equifax, Experian, or TransUnion.


THE CREDIT FILE "DATA MAP"

Credit applicant bureau files arrived as legacy platform (mainframe) encrypted export data that, once unlocked, simply comprised variable-length ASCII files containing fixed-position row/column headers denoting each subsequent sequential following data element (with the respective data types and field lengths defined by a standard "data dictionary" - i.e. "data maps" guiding the import conversion specifications). Such files are necessarily "variable length" owing to the fact that every person's credit history differs, both in length of history and relative periodic intensity of activity and breadth of credit utilization.

A bit of relatively unremarkable programming, and the import "data map" routines are done.

How a person's health/medical transactional history differs materially in concept from that escapes me. For example, a core HIT industry consensus standard -- HL7 -- exists for interoperable transmission of medical information messaging. It simply specifies a "data map" wherein health data elements are identified by their relative position within an ASCII file, each datum preceded by a coded identifier readable by an HL7-enabled destination interpreter, e.g.

"HL7 messages are in human-readable (ASCII) format, though they may require some effort to interpret.

Each message consists of one or more segments. A carriage return character (\r, which is 0D in hexadecimal) separates one segment from another. Each segment is displayed on a different line of text."

This is all rather Old School, actually.

To be fair, data in individual medical files extend beyond the IT-mundane alphanumeric items comprising credit bureau compilations, principally with respect to bandwidth-intensive graphic imaging files, e.g., x-ray and other scans (PACS output), EKG graphs, and so forth. However, such imaging data might simply be be made effectively accessible via secured proxy hyperlink reference (thereupon downloadable as needed) rather than traveling pixel-by-pixel with the textual/alphanumeric data constituting the bulk of transactional health records.

In sum, there seems to exist a functionally mature mega-scale infrastructure already in place, one that securely and efficiently manages perhaps close to 200 terabytes of data ongoing, 24/7, capable of near-instant accessibility/turnaround.

PUSHBACK?

It almost writes itself. Beyond the turf-protective antipathy likely to be voiced by existing regional HIE organizations that have labored mightily to date, credit reporting firms are far from the most beloved of corporate entities. Everyone seems to have his or her pet horror story (as do my wife and I). Widespread, chronic inaccuracies in consumer financial information are bad enough. Trafficking in error-ridden personal medical data would be orders of magnitude worse, sometimes lethally so. Also, we are unhappily witness to ongoing "mission creep" as bureau pulls get used to vet people for decisions having nothing directly to do with the properly limited legitimate purpose of creditworthiness evaluation: Hiring decisions, apartment rentals, actuarial model insurance policy rate setting, etc**.

** Not to mention the poignantly hyperbolic cast of derisive Palinistas and indignant fellow traveler Tea Baggers who reflexively see "Federal Death Panels" lurking behind every tree stump, shrub, USB port, and T-1 line (particularly when the cameras are rolling), and who will no doubt breathlessly spin HIE data distribution as inexorable grist for exactly that.

Nonetheless, those are policy issues that can be reconciled legislatively and via subsequent regulation (to the sufficient satisfaction of the sane, in any event). My speculation goes to the availability of an extant but possibly overlooked yet scale-and-technology viable digital infrastructure that might expedite the goal of universal, standarized HIE.

Perhaps neither Equifax, Experian, nor TransUnion would have any interest in getting involved in HIE (What would be the viable business model? What is the quantifiable fair-market value of timely access to individual and aggregate health information?). I simply don't know. But, it's a question worth asking, in light of their long experience dealing with secure, large-scale transactions of highly sensitive data.

THE HIT DATA SECURITY/PRIVACY ISSUES

Coming shortly. Google "Latanya Sweeney" and "Deborah C. Peel" for starters. If you take everything these two prominent critics have to say at face value, you'll be anxiously aching to get off the wire (and the wireless) and off the grid and off to the far reaches of some inaccessible somewhere that no longer exists.

Stay tuned...
___

DISCLAIMER: I composed the foregoing wholly on my own time and my personal computer at home. The views proffered are expressly my own as a concerned and active citizen/taxpayer, and in no way reflect any policy views of my employer, notwithstanding that some of the thinking has indeed obviously been spurred by the implications of the new work with which I am now charged.