Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 19 2012

Why health IT systems integrate poorly today, and what future EHRs can do about it

Physicians, patients, healthcare providers, and other health industry participants have been clamoring for modernization of health IT systems for years. Recently, the HITECH Act, meaningful use, and other major government initiatives led by the Office of the National Coordinator (ONC) have been accelerating the demand. Unfortunately, as stated eloquently in the recent New England Journal of Medicine (NEJM) article "Escaping the EHR Trap - The Future of Health IT," health IT systems are trapped in legacy infrastructures:

"It is a widely accepted myth that medicine requires complex, highly specialized information-technology (IT) systems. This myth continues to justify soaring IT costs, burdensome physician workloads, and stagnation in innovation — while doctors become increasingly bound to documentation and communication products that are functionally decades behind those they use in their 'civilian' life."

The problem is not that engineers don't know how to create the right technology solutions or that we're facing a big governance problem. Rather, the real cross-industry issue is much bigger: Our approach and the methods we have chosen for integration are opaque, decades old, and they reward closed systems. Drs. Mandl and Kohane summarize it well in their NEJM article by saying "a few companies controlling much of the market remain entrenched in 'legacy' approaches, threatening other vendors' viability." They elaborated further on what they feel is the reason:

"We believe that EHR [electronic health record] vendors propagate the myth that health IT is qualitatively different from industrial and consumer products in order to protect their prices and market share and block new entrants. In reality, diverse functionality needn't reside within single EHR systems, and there's a clear path toward better, safer, cheaper, and nimbler tools for managing healthcare's complex tasks."

From the 1950s through the mid-1990s, systems integration required every system to know about each other in advance, agree on what data they would share, engage in governance meetings, put memoranda of understanding or contracts in place, and so on. In the age of the web, the approach has changed to one where the owner of the data provides whatever they decide (e.g., through a web server) and whoever wants it can come get it through a secure access method (e.g., through a browser or HTTP client). This kind of revolutionary approach in systems integration is what the health IT and medical device sectors are sorely lacking, and something that ONC, the U.S. Department of Health and Human Services (HHS) and the National Institute of Standards and Technology (NIST) can help promote. No amount of government money will solve health IT integration issues so long as our approach is incorrect.

As users of health IT systems, Drs. Mandl and Kohane have identified the problem of legacy approaches doing a lot of damage. What can we in the technology industry do to help? Let's take a look at the major issues holding back modernization of IT and integration of systems in healthcare, and what the government and systems owners — such as EHR vendors — can do about it.

We don't support shared identities, single sign on (SSO), and industry-neutral authentication and authorization

Most health IT systems create their own custom logins and identities for users, storing metadata about roles, permissions, access controls, etc., in an opaque part of a proprietary database. Without identity sharing and exchange, there can be no easy and secure application integration capabilities, no matter how good the formats are. ONC should mandate that all future EHRs use industry-neutral and well supported identity management technologies so that each system has at least the ability to share identities. ONC does not need to do anything new — they can can simply piggyback on the The White House's National Strategy for Trusted Identities in Cyberspace (NSTIC) that is already defined and being managed by the National Institutes for Standards and Technology (NIST).

I'm continually surprised how little attention is paid to this cornerstone of application integration. There are very nice open identity exchange protocols, such as SAML, OpenID, and OAuth, as well as open roles and permissions-management protocols, such as XACML, that allow identity and permission sharing. Free open source tools such as OpenAM, Apache Directory, OpenLDAP, Shibboleth, and many commercial vendors have drop-in tools to make it almost trivial to do identity sharing, SSO, attribute-based access control (ABAC), and role-based access control (RBAC). It's quite hard to believe, but most current enterprise health IT systems don't even support Active Directory or LDAP.

We're too focused on "structured data integration" instead of "practical app integration" in our early project phases

In the early days of data collection and dissemination (it's sad to say that after 50 years of computing, health IT is still in those early days, but it's true), it's not important to share structured data at detailed machine-computable levels. Instead, different applications need immediate access to portions of data they don't already manage. When industries take on structured data integration too early, they often waste time because they don't understand the use cases well enough to specify best-case solutions. Poor implementations result.

For example, instead of asking for HL7 (the health IT vendors' evolved standard) or other structured data about patients, we can use simple techniques like HTML widgets to share "snippets" of our apps. Widgets are portions of apps that can be embedded or "mashed up" in other apps without tight coupling. The Department of Veterans Affairs' successful Blue Button approach has demonstrated the power of app integration versus structured data integration. It provides immediate benefit to users while the data geeks figure out what they need for analytics, computations, etc.

Once app integration, SSO, identity sharing, and simple formats like JSON are in good shape, we can shift our focus to structured data integration, with all the governance and analytics associated with it. Future EHRs must master the production and consumption of secure authenticated application widgets using industry-standard approaches such as JavaScript and JSON.

We focus more on "pushing" versus "pulling" data than is warranted early in projects

A question we commonly ask at the beginning of every integration project is "what data can you send me?" This is called the "push" model, where the system that contains the data is responsible for sending the data to all those who are interested (or to some central provider, such as a health information exchange). What future EHRs should do is implement syndicated Atom-like feeds (which could contain HL7 or other formats) for all the data they can share and allow anyone who wants it to subscribe to the data. This is called the "pull" model. Data holders allow secure authenticated subscriptions to their data and don't worry about direct coupling with other apps. If our future EHRs became completely decoupled, many of our integration problems would go away. Using ATOM and JSON as formats, the Open Data Protocol (oData), which has free open source implementations, should be used to actually open patient data in days rather than months.

To make sure security and privacy are maintained in the decoupled systems, automated auditing of protected health information can be enabled by logging data transfers through use of syslog and other reliable methods with proper access control rules expressed in standards like XACML.

We're too focused on heavyweight industry-specific formats instead of lightweight or micro formats

Appointment scheduling in the health IT ecosystem is a major source of health IT integration pain (in fact, much worse than most other areas). If EHRs just used industry-standard iCalendar/ICS publishing and subscribing we could solve, based on my experience, a large majority of appointment schedule integration problems. Think about how your iPad can sync with your Outlook/Exchange server at work — it's not magic; it's an industry-neutral standard widely used and supported.

Another example of outmoded industry practice is the use of HL7 ADTs for patient profile exchanges instead of more common and better supported SAML (which emerged to meet the need for industry-neutral user identities and profile exchange). If you've ever used your Google account/profile to log into another app on another website, you're using SAML. Again, no magic. It works millions of times a day with "good enough" security and user-controlled privacy.

Data emitted is not tagged using semantic markup, so it's not securable or shareable by default

In many existing contracts CIOs have signed, the vendors of systems that house the data also "own" the data. The data can't be easily liberated because the vendors actively prevent it from being shared. The healthcare industry sets up large data governance structures where vendors are cajoled and are often begged for access to patient data, but vendors claim that it's not easy or not possible because health data is special. However, Drs. Mandl and Kohane, like me, think otherwise and clearly state "some types of data used in healthcare are stored and used in ways that are unique to the medical field, but the field is not unusual in its need to share data across diverse electronic systems." Even when systems are opened up after data governance establishes the sources and sinks of data along with specifications of data ownership rules, vendors only do the minimal tagging possible. They do structured data integration and then present information on the screen (usually as HTML), failing to tag data with proper semantic markup when it's basically free to do (no extra development is required).

One easy way to create semantically meaningful patient data is to have all HTML tags generated with companion RDFa or HTML5 Data Attributes using industry-neutral schemas and microformats similar to the ones defined at Using microformats and RDFa as a start, EHRs can then start tagging (in backward-compatible HTML) so that it's easier to discover metadata and allow simple securing and sharing of data. None of this is technically challenging if we really care about integration and are not just giving it lip service. Google's recent implementation of its Knowledge Graph is a great example of the utility of this semantic mapping approach. Once even basic microformats are in place with RDFa for authenticated or unauthenticated semantic tagging, we can then create SPARQL endpoints to make data easier to understand.

When health IT systems produce HTML, CSS, JavaScript, JSON, and other common outputs, it's not done in a security- and integration-friendly manner

Future EHRs should start to use industry-neutral CSS frameworks like Twitter's Bootstrap (which is free and open source). When using JavaScript, EHRs should use common lightweight and integration-friendly libraries like jQuery, instead of JavaScript frameworks that take over the app and prevent easy discovery and integration. Lastly, instead of emitting just complex XML or non-semantically aware HTML, EHRs should emit JSON from APIs so client-side applications can be easily written to take advantage of data. Also, they should be sure to offer both JSON and JSONP so that integration can occur more easily without getting into security problems, like cross-site scripting. Modern engineers who care about integration should always assume that their user interfaces (UI) might be "scraped" or connected to other systems. These interfaces should make it easy for others to securely take UI-focused data and create secure secondary uses.

All of these techniques I've mentioned are widely accepted secure web practices that need to make their way into our EHRs. Drs. Mandl and Kohane summed up the benefits of these approaches perfectly in their NEJM article:

"Health IT vendors should adapt modern technologies wherever possible. Clinicians choosing products in order to participate in the Medicare and Medicaid EHR Incentive Programs should not be held hostage to EHRs that reduce their efficiency and strangle innovation. New companies will offer bundled, best-of-breed, interoperable, substitutable technologies — several of which are being developed with ONC funding — that can be optimized for use in healthcare improvement. Properly nurtured, these products will rapidly reach the market, effectively addressing the goals of 'meaningful use,' signaling the post-EHR era, and returning to the innovative spirit of EHR pioneers."

I'll go one step further and say that the government's multi-billion-dollar incentives push won't do much if the technical methods and approaches being promoted don't match the commonly accepted, lightweight, and modern approaches mentioned above.

OSCON 2012 Healthcare Track — The conjunction of open source and open data with health technology promises to improve creaking infrastructure and give greater control and engagement to patients. Learn more at OSCON 2012, being held July 16-20 in Portland, Oregon.

Save 20% on registration with the code RADAR


June 11 2012

Four short links: 11 June 2012

  1. When Code Can Kill or Cure (The Economist) -- I've linked to the dangers of closed source devices before, but this caught my eye: "In the 1990s we developed an excellent radiation-therapy treatment-planning system and tried to give it away to other clinics," says Dr Mackie. "But when we were told by the FDA that we should get our software approved, the hospital wasn't willing to fund it." He formed a spin-off firm specifically to get FDA approval. It took four years and cost millions of dollars. The software was subsequently sold as a traditional, closed-source product.
  2. Gut Fungus (Wired) -- the microbiome of bacteria in your body is being studied, but now researchers have scoured the poop of different species and found different mycological populations in each, and linked them to diseases.
  3. Evaluating the Harm from Closed Source (Eric Raymond) -- whether or not you argue with his ethics, you will appreciate the clear description of the things you're trading off when you choose to use closed source software.
  4. PyBossa -- a free, open-source, platform for creating and running crowd-sourcing applications that utilise online assistance in performing tasks that require human cognition, knowledge or intelligence such as image classification, transcription, geocoding and more! (via The Open Knowledge Foundation)

Sponsored post

January 23 2012

Four short links: 23 January 2012

  1. Adafruit Flora -- wearable electronics and accessories platform. (via Tim O'Reilly)
  2. Killed by Code -- paper on software vulnerabilities in implantable medical devices. Discovered via Karen Sandler's wow-generating keynote at (covered here). (via Selena Deckelmann)
  3. DIY London -- fun little Budget-Hero game to make apparent the trade-offs facing politicians. Kids should play Sim* and Civilization games: you get a sense of tradeoffs and consequences from these that you don't from insubstantial activities. More City Hall games, please! (via David Eaves)
  4. Lessig on How Money Corrupts Congress (Rolling Stone) -- glad to see Larry's profile rising. This is key: I lay out my own voucher program that tries to do that, but the challenge isn’t as much to imagine the solution as much as it is to imagine the process to bring about the solution, given how entrenched the cancer is and how much the very people we need to reform the system depend upon the existing system. (see also an excerpt from Lessig's new book) (via Long Now)

November 03 2011

Developer Week in Review: The hijacking of an insulin pump

A future batch of kindlingIt was a great week at the Turner household! Although we love our house, we've frequently said to each other, "You know what we could really use? A 25-foot-long tree limb wrapped in power lines blocking our driveway." Well, this weekend mother nature decided to help us fill this void in our landscaping, and threw in some ornamental cherry firewood as well (chainsawing not included). Thankfully, I spent the extra bucks on Saturday to get our LPG tank topped off, so I've got generator power for 10-14 days. Given we're on day four with no power in sight, that was a good decision.

It could have been worse, of course. For example ...

A scene from an upcoming technothriller

Plucky researcher Ann McManna walked across the room toward the podium, ready to reveal the details of the fiendish plot she had uncovered to the waiting reporters. Now the world would know about the conspiracy to corner the world supply of macadamia nuts. Her heart pounded with excitement, her mouth was dry and she perspired, in spite of the air conditioning that was making the room practically an ice box. As she approached the stage, she bumped against a table, stumbling and suddenly having trouble seeing her path through blurry eyes. Something was wrong, but she couldn't focus, couldn't identify what was happening to her, even as she collapsed to the ground. Minutes later, the paramedics would close the eyelids of her corpse.

Some fanciful invention of Tom Clancy or Robin Cook? Not anymore, thanks to research by McAfee's Barnaby Jack, presented at this year's Hacker Halted conference. Using some custom software and a special antenna, Jack was able to control Medtronic insulin pumps as far as 300 feet from the controller. He was able to disable the tones that warn a user that insulin is being pumped, and trigger a 25-unit bolus of insulin. In some circumstances, this could kill a victim.

As networked computers appear in more life-critical items, this is a good reminder that security should be job No. 1, not something to think about if you have time. Too many proprietary device manufacturers seem to depend on security through obscurity, rather than security in depth.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

The first taste is free, but you'll be back

One of the perils of depending on public APIs from for-profit companies is that they may get turned into a profit center down the road. Users of the Google Maps API learned that lesson recently, as Google announced that high-volume users will no longer have free access to the APIs starting next year. Before you start panicking, the definition of high-volume will be more than 25,000 calls a day (2,500 if you use the custom styling features), and the rate over 25,000 is $4/1,000 calls. Google claims that less than 1% of all users will run up against this limit.

The problem with using beta or "free" services in your products is that, unless the terms of use specifically say that it will be free forever, you have no contractual agreement to lean on, and the provider is able at any point to change how (or even if) the service is provided.

Linus Torvalds vs. C++

Linux progenitor Linus Torvalds has a reputation for diplomacy and fence building — that's practically the only way to herd the stampede of cats that is the Linux developer community. But when he gets upset, the results can peel the paint off the walls.

We got a good example this week, as Torvalds responded to a complaint about the fact that the git source control system was written in pure C, rather than C++. In a nutshell, Torvalds called C++ a lousy language that attracts substandard programmers and leads to sloppy, unmaintainable code. In general, I tend to take any blanket condemnation of a programming language as hyperbole, but Torvalds seems to genuinely loathe C++. We'll have to see if his anger against the language alienates any of the kernel developer base, or if people will just shrug it off as Linus being Linus.

Got news?

Please send tips and leads here.


Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...