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 06 2012

Who owns patient data?

Who owns a patient's health information?

  • The patient to whom it refers?
  • The health provider that created it?
  • The IT specialist who has the greatest control over it?

The notion of ownership is inadequate for health information. For instance, no one has an absolute right to destroy health information. But we all understand what it means to own an automobile: You can drive the car you own into a tree or into the ocean if you want to. No one has the legal right to do things like that to a "master copy" of health information.

All of the groups above have a complex series of rights and responsibilities relating to health information that should never be trivialized into ownership.

Raising the question of ownership at all is a hash argument. What is a hash argument? Here's how Julian Sanchez describes it:

"Come to think of it, there's a certain class of rhetoric I'm going to call the 'one-way hash' argument. Most modern cryptographic systems in wide use are based on a certain mathematical asymmetry: You can multiply a couple of large prime numbers much (much, much, much, much) more quickly than you can factor the product back into primes. A one-way hash is a kind of 'fingerprint' for messages based on the same mathematical idea: It's really easy to run the algorithm in one direction, but much harder and more time consuming to undo. Certain bad arguments work the same way — skim online debates between biologists and earnest ID (Intelligent Design) aficionados armed with talking points if you want a few examples: The talking point on one side is just complex enough that it's both intelligible — even somewhat intuitive — to the layman and sounds as though it might qualify as some kind of insight ... The rebuttal, by contrast, may require explaining a whole series of preliminary concepts before it's really possible to explain why the talking point is wrong."

The question "Who owns the data?" presumes that the notion of ownership is valid, and it jettisons those foolish enough to try to answer the question into a needless circular debate. Once you mistakenly assume that the question is answerable, you cannot help but back an unintelligible position.

Ownership is a poor starting point for health data because the concept itself doesn't map well to the people and organizations that have relationships with that data. The following chart shows what's possible depending on a given role.

Person / Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the provider's copy of the data Append to the provider's copy of the data Acquire copies of HIPAA-covered data Sourcing Provider No. HIPAA mandates that the provider who creates HIPAA-covered data must ensure that a copy of the record is available. Mere deletion is not a privilege that providers have with their copies of patient records. Most EHR systems enforce this rule for providers.

No. While providers can change the contents of the EHR, they are not allowed to change the contents without a log of those changes being maintained. Many EHRs contain the concept of "signing" EHR data, which translates to "the patient data entering the state where it cannot be changed without logging anymore."

Yes. Providers can correct their copy of the EHR data, providing they maintain a copy of the incorrect version of the data. Again, EHR software enforces this rule.
Yes. The providers can merely add to data, without changing the "correctness" of previous instances of the data. EHR systems should seamlessly handle this case.
Sometimes. Depending on the ongoing "treatment" status of the patient, providers typically have the right to acquire copies of treatment data from other treating providers. If they are "fired," they can lose this right.
  Person / Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the provider's copy of the data Append to the provider's copy of the data Acquire copies of HIPAA-covered data
Patient rights Yes, they can delete their own copies of their patient records, but requests to providers that their charts be deleted will be denied.
No. Patients cannot change the "canonical" version of a patient record.

No. While patients have the right to comment on and amend the file, they can merely suggest that the "canonical" version of the patient record be updated.

Yes. The patient has the right to append to EHR records under HIPAA. HIPAA does not require that this amendment impact the "canonical" version of the patient record, but these additions must be present somewhere, and there is likely to be a substantial civil liability for providers who fail to act in a clinically responsible manner on the amended data. The relationship between "patient amendments" and the "canonical version" is a complex procedural and technical issue that will see lots of attention in the years to come.

Usually. Patients typically have the right to access the contents of an EHR system, assuming they pay a copying cost. EHRs frequently make this copying cost unreasonable, and the results are so dense that they are not useful. There are also exceptions to this "right to read," including psychiatric notes and legal investigations.
  Person / Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the provider's copy of the data Append to the provider's copy of the data Acquire copies of HIPAA-covered data
True Copyright Ownership (i.e. the relationship you have with a paper you have written or a photo you have taken) Yes. You can destroy things you own. Yes. You can change things you own without recording what changes you made. No. If you hold copyright to material and someone has purchased a right to a copy of that material, you cannot make them change it, even if you make "corrections." Sometimes, people use licensing rather than mere "copy sales" to enforce this right (i.e. Microsoft might have the right to change your copy of Windows, etc.).
No. Again, you have no rights to change another person's copy of something you own the copyright to. Again, some people use licensing as a means to gain this power rather than just "sale of a copy."
No. You do not have an automatic right to copies of other people's copyrighted works, even if they depict you somehow. (This is why your family photographer can gouge you on reprints.)   Person / Privilege Delete their copy of data Arbitrarily (without logs) edit their copy of data Correct the provider's copy of the data Append to the provider's copy of the data Acquire copies of HIPAA-covered data

IT Specialist

Kind of. Regulations dictate that IT specialists and vendors should not have the right to delete patient records. But root (or admin) access to the underlying EHR databases ensure that only people with backend access can truly delete patient records. Only people with direct access to source code or direct access to the database can completely circumvent EHR logging systems. The "delete privilege" is somewhat difficult to accomplish entirely without detection, however, since it is likely that someone (i.e. the patient) will know that the record should be present.

Yes. Source code or database-level access ensures that patient records can be modified without logging.

Yes. Source code or database-level access ensures that patient records can be modified without logging.

Yes. Source code or database-level access ensures that patient records can be modified without logging.

No. Typically, database administrators and programmers do not have the standing to request medical records from other sources.

Ergo, neither a patient nor a doctor nor the programmer has an "ownership" relationship with patient data. All of them have a unique set of privileges that do not line up exactly with any traditional notion of "ownership." Ironically, it is neither the patient nor the provider (when I say "provider," this usually means a doctor) who is closest to "owning" the data. The programmer has the most complete access and the only role with the ability to avoid rules that are enforced automatically by electronic health record (EHR) software.

So, asking "who owns the data?" is a meaningless, time-wasting, and shallow conceptualization of the issue at hand.

The real issue is: "What rights do patients have regarding healthcare data that refers to them?" This is a deep question because patient rights to data vary depending on how the data was acquired. For instance, a standalone personal health record (PHR) is primarily governed by the end-user license agreement (EULA) between the patient and the PHR provider (which usually gives the patient wildly varying rights), while right to a doctor's EHR data is dictated by both HIPAA and Meaningful Use standards.

Usually, what people really mean when they say "The patient owns the data" is "The patient's needs and desires regarding data should be respected." That is a wonderful instinct, but unless we are going to talk about specific privileges enabled by regulation or law, it really means "whatever the provider/programmer holding the data thinks it means."

For instance, while current Meaningful Use does require providers to give patients digital access to summary documents, there is no requirement for "complete" and "instant" access to the full contents of the EHR. While HIPAA mandates "complete" access, the EHR serves to make printed copies of digitized patient data completely useless. The devil is in the details here, and when people start going on about "the patient owning the data," what they are really doing is encouraging a mental shortcut that cannot readily be undone.

Note: This is a refresh of an article originally published here. Photo on home and category pages: Stethoscope by rosmary, on Flickr

Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a Rosetta Stone for the IT implementer who wants to help organizations harness EHR systems.


May 24 2012

Strata Week: Visualizing a better life

Here are a few of the data stories that caught my attention this week:

Visualizing a better life

How do you compare the quality of life in different countries? As The Guardian's Simon Rogers points out, GDP has commonly been the indicator used to show a country's economic strength, but it's insufficient for comparing the quality of life and happiness of people.

To help build a better picture of what quality of life means to people, the Organization for Economic Cooperation and Development OECD built the Your Better Life Index. The index lets people select the things that matter to them: housing, income, jobs, community, education, environment, governance, health, life satisfaction, safety and work-life balance. The OECD launched the tool last year and offered an update this week, adding data on gender and inequality.

Screenshot from OECD's Your Better Life Index.

"It's counted as a major success by the OECD," writes Rogers, "particularly as users consistently rank quality of life indicators such as education, environment, governance, health, life satisfaction, safety and work-life balance above more traditional ones. Designed by Moritz Stefaner and Raureif, it's also rather beautiful."

The countries that come out on top most often based on users' rankings: "Denmark (life satisfaction and work-life balance), Switzerland (health and jobs), Finland (education), Japan (safety), Sweden (environment), and the USA (income)."

Researchers' access to data

The New York Times' John Markoff examines social science research and the growing problem of datasets that are not made available to other scholars. Opening data helps make sure that research results can be verified. But Markoff suggests that in many cases, data is being kept private and proprietary.

Much of the data he's talking about here is:

"... gathered by researchers at companies like Facebook, Google and Microsoft from patterns of cellphone calls, text messages and Internet clicks by millions of users around the world. Companies often refuse to make such information public, sometimes for competitive reasons and sometimes to protect customers' privacy. But to many scientists, the practice is an invitation to bad science, secrecy and even potential fraud."

"The debate will only intensify as large companies with deep pockets do more research about their users," Markoff predicts.

Updates to Hadoop

Apache has released the alpha version of Hadoop 2.0.0. We should stress "alpha" here, and as Hortonworks' Arun Murthy notes, it's "not ready to run in production." However, he adds the update "is still an important step forward, as it represents the very first release that delivers new and important capabilities," including: HDFS HA (manual failover) and next generation MapReduce.

In other Hadoop news, MapR has unveiled a series of new features and initiatives for its Hadoop distribution, including release of a fully compliant ODBC 3.52 driver, support for the Linux Pluggable Authentication Modules (PAM), and the availability of the source code for several of its components.

Have data news to share?

Feel free to email me.

OSCON 2012 — Join the world's open source pioneers, builders, and innovators July 16-20 in Portland, Oregon. Learn about open development, challenge your assumptions, and fire up your brain.

Save 20% on registration with the code RADAR


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 ...