In 1979 a Federal judge in Florida sided with the AMA to prevent these kinds of provider-specific data sets violated doctor privacy. Last Friday, a different Florida judge reversed the 1979 injunction, allowing provider identified data to be released from CMS under FOIA requests. Even without this tremendous victory for the Wall Street Journal, there was already a shift away from aggregation studies in healthcare towards using Big Data methods on specific doctors to improve healthcare. This critical shift will allow us to determine which doctors are doing the best job, and which are doing the worst. We can target struggling doctors to help improve care, and we can also target the best doctors, so that we can learn new best practices in healthcare.

Evidence-based medicine must be targeted to handle specific clinical contexts. The only really open questions to decide are “how much data should we relese” and “should this be done in secret or in the open.” I submit that the targeting should be done at the individual and team level, and that this must be an open process. We need to start tracking the performance and clinical decisions of specific doctors working with other specific doctors, in a way that allows for public scrutiny. We need to release uncomfortably personal data about specific physicians and evaluate that data in a fair manner, without sparking a witch-hunt. And whether you agree with this approach or not, it’s already underway. The overturning of this court case will only open the flood gates further.

Last year, I released DocGraph at Strata RX. DocGraph details how specific doctors and hospitals team together to deliver healthcare. (data on referral patterns, etc). At that conference we (Not Only Development) promised that this data set would go Open Source eventually. This month, we will be announcing that the DocGraph data set is available for costless download.  But there are two other data sets that can now be used to make that graph data much richer.

“Graph” or “network” data, in this context, refers to a computing technique that represents nodes (in this case doctors, hospitals, etc.) connected by edges (in this case, representing which doctors and hospitals work together). So DocGraph explicitly states that Dr. Smith (a primary care doctor) is working with Dr. Jones (a cardiologist), and assigns a strength to that relationship.

In order to take a network graph approach to modeling the healthcare system, you have to name names. We have had named, specific, and incriminating data on US hospitals for years now. This openness has been at the heart of a revolution in the field of patient safety. I believe that this openness has been a central motivator for the ongoing reduction of “never events”, perhaps even more important than corresponding payment reforms. On some cases, I even have data to back this assertion.

I am a devotee of new thinking about human motivation and I believe very strongly the most doctors, even the “bad” ones, want to be the best they can at what they do, largely independent of financial incentives. But doctors need uncomfortably personal data on how they, specifically, are doing in order to start doing it better.

This has been the month for the open release of uncomfortably personal data about the healthcare system.

First, HHS announced the release of data on master charge sets for hospitals. This is likely a direct response to the problems with master charge sets in the masterful Bitter Pill: Why Medical Bills Are Killing Us article by Steven Brill in Time Magazine. The data released by CMS is a complex data set about an even more complex medico-legal issue, but a useful oversimplification is this: it shows which hospitals have been the worst abusers of cash-paying, uninsured patients. You could write entire articles about the structure, value, and depth of this data set…and I plan to, given infinite time and resources.

But then, in the midst of this, Propublica released data on the prescribing patterns of almost every doctor in the US. This is detailed information about the preferences of almost every doctor who participates in the Medicare Part D prescription program, which is almost every doctor. Does your doctor prefer Oxycontin to Vicodin? Which antibiotic does your doctor use most frequently? These choices, taken together, can be called a “prescribing pattern.” Propublica is allowing the public to view those patterns for specific doctors.

These data sets are having a combinatorial impact for those of us who are interested in researching the healthcare system.

Now you can see if your doctor is a conservative ( o 1 2 3 4 5) or a liberal (1 2 3) prescriber, and you can see if they refer patients to a hospital that charges more than double what the one across the street does.

Taken together, these changes in data release policy represent two important shifts in the analysis of the healthcare system. We are moving from proprietary analysis to open analysis and from aggregate data to graph (network) data. These moves parallel past scientific process breakthroughs:

Proprietary science -> Open Science: illustrated by the move from Alchemy to Chemistry. Alchemists were famous for doing work in secret, hoping to learn and horde the secrets for turning lead into gold or the secret to eternal life. Chemistry began when researchers gave up secrecy and started sharing important results openly.

Aggregate models -> Network models: illustrated by the move from chromosomal models of genetic inheritance to omic (genomic/proteomic/etc.) network models of genetic inheritance. Mendel could spot patterns in the colors of his peas because the those genes operated on the chromosomal level. The chromosome acts as a natural phenotypical aggregator for a much more complex genetic processes. But that aggregation limits what can be studied. The discovery of DNA allowed researchers to start analyzing inheritance using network models.

For years, there has been a proprietary market for data about how doctor behave, specifically around prescribing patterns. IMS, for instance, is a leading data vendor for this information. If you had wanted to purchase prescribing or referral pattern data, IMS will happily provide it (hint: you can’t afford it). Despite the high barrier to access, IMS’s service has been very unpopular with doctors, and the AMA successfully lobbied for a mechanism that would allow for a doctor to opt-out of these prescribing databases. So there is a well-established data vendor community here, with some recent Big Data entrants.

Two companies using Big Data graph analysis methods on doctor data have had high-profile funding events. Activate Networks was funded for 10 million in series B and Kyruus received 11 million in series B. The list of  people at Kyruus and people at Activate Networks are filled with the rock stars of this nascent industry; who have published seminal papers in the field. However, like IMS, these companies are pursuing proprietary data approach to graph analysis of the healthcare system.

This is not necessarily by choice—most doctor data is released reluctantly by data owners. They are concerned with ensuring that doctor data does not spill into the public domain. In order to run their businesses, IMS, Activate, and Kyruus have likely made contractual promises that require them to keep of much of the data that they have access to private. In short, these companies are “behind the curtain” of healthcare informatics. They get substantial benefits by having access to this kind of private healthcare data and they must accept certain limitations in its use. My limited interactions with these companies has shown that they are as enthusiastic about open data in healthcare as I am.

When even proprietary players want to shift to more open accountable data models, it is fair to say that this shift is widely accepted. As a society, it is critical for us to move this graph healthcare data, as much as possible, into the open. This will allow data scientists from IMS, Activate, Kyruus and others to collaborate with journalists, academics and the open source developer community to make doctor and hospital performance into an open science. HHS has done its part by proactively releasing new critical data sets and by electing not to “fight” FOIA requests that seek even more data. This is substantive evidence that the mission of open data, inspired by President Obama and implemented by Federal CTO Todd Park, is a reality.

The second shift is away from aggregate models for healthcare researchers. While Propublica, Kyruus, and Activate have the Big Data chops to lead this shift, the rank and file healthcare researcher still routinely uses aggregate data to analysis the healthcare system as the method of choice. This is true of academic researchers, healthcare industry administrators, and policy makers alike. Understanding statistics is really the first step towards being a well-rounded data scientist, but it is only the first step.

Traditional statistical approaches, like traditional economic approaches, are powerful because they make certain simplifying assumptions about the world. Like many generalizations they are useful cognitive shortcuts until they are too frequently proven untrue. There is no “normal” prescribing pattern, for instance, to which a given provider can be judged.

Using averages, across zipcode, city, state or regional boundaries is a useful way to detect and describe the problems that we have in healthcare. But it is a terrible way to create feedback and control loops. An infectious disease clinic, for instance, will be unperturbed to learn that it has a higher “rate of infection” scores than neighboring clinics. In fact they are a magnet for infection cases, and hopefully should have a higher infection “case loads”, but a lower “infection” rates. Many scoring systems are unable to make these kinds of distinctions. Similarly, a center for cancer excellence would not be surprised to learn that they have a shorter life span scores then other cancer treatment centers. Any “last resort” clinical center would show those effects as the attract the most difficult cases.

It is difficult to use averages, scores, and other simplistic mathematical shortcuts to detect real problems in healthcare. We need a new norm where the average healthcare researcher’s initial tool of choice is Gephi rather than Excel and Neo4J rather than SQL. The aggregate approach has taken the healthcare system this far, but we need to have deeper understandings of how the healthcare system works—and fails—if we want to achieve the triple aim. We need models that incorporate details about specific doctors and hospitals. We need to move from simplistic mathematical shortcuts to complex mathematical models, Big Data if you like that term.

We need to have both shifts at the same time. It is not enough to have the shift to open data, in aggregate, or the shift to network models trapped behind the “insiders curtain”.  That has been happening for years and this creates troubling power dynamics. When the public can see only averages, but the insiders get to see the graph of healthcare, we will enjoy only narrow optimizations and limited uses.

Currently, there is no simple way for data scientists at an EHR company, an insurance company, and a drug company to teach each other how to better leverage the healthcare graph. Each of these companies has a lens on the “true” graph created using only a slice of the relevant data. but the limitations of the data are really the least of the problems facing these researchers working in isolation. For each data scientist, working in isolation, there is no way to generally test hypothesis with outsiders. There is no way to “stand back and try science” because science is a community process.

We need to create a community of healthcare graph researchers and provide that community with non-aggregate data it needs to create the algorithms that will dictate how medicine operates for the next century. This is not a project for any single company to take on; we are betting too much as a society to have that kind of pressure. No company or data scientist I know of even wants that kind of role. Instead, every company in the space is interested in leveraging and contributing open data, so that the hypothesis and methods developed “behind the curtain” can be validated in the open.

Before the release of these three data sets, data scientists were in the tremendously uncomfortable position of having to make critical business decisions while being only “probably” right. Given the ease with which “probably right” can turn into “completely wrong” with data, we should work hard to ensure that data scientists are not put in this position again.

Strata Rx Heath Data Conference — Strata Rx brings together the diverse communities driving innovations in big data analytics for health care. Learn about the transformation of health care through big data and how to position your company to benefit from these trends. Learn more.

As I recently described on the DocGraph mailing list, work is underway to acquire the data sets that we set out to merge. The issue deals with file formats.

The core identifier for doctors, hospitals and other healthcare entities is the National Provider Identifier (NPI). This is something like a Social Security number for doctors and hospitals. In fact it was created in part so that doctors would not need to use their Social Security numbers or other identifiers in order to participate in healthcare financial transactions (i.e. paid by insurance companies for their services). The NPI is the “one number to rule them” in healthcare and we want to map data from other sources accurately to that ID.

Each state releases none, one or several data files that can be purchased and also contain doctor data. But these file downloads are in “random file format X.” Of course we are not yet done with our full survey of the files and their formats, but I can assure you that they are mostly CSV files and a troubling number of PDF files. It is our job to take these files and merge them against the NPI, in order to provide a cohesive picture for data scientists.

But the data available from each state varies greatly. Sometimes they will have addresses, sometimes not. Sometimes they will have fax numbers, sometimes not, sometimes they will include medical school information, some will not. Sometimes they will simply include the name of the medical school, sometimes they will use a code. Sometimes when they use codes they will make up their own …

I am not complaining here. We knew what we were getting ourselves into when we took on the DocGraph project. The community at large has paid us well to do this work! But now we have a question? What data formats should we support?

The simple answer is that everyone can handle JSON, XML or CSV and we will probably end up supporting all of those formats to some degree. XML is famous for its capacity to handle “constraints” that solve some or all of the problems that we are considering addressing. Of course, there is some work on similar constraint systems for JSON. This guy thinks more is needed, This guy thinks less is needed. Both of them seem to have thought about it more than I have.

What I am concerned with is how to architect the schema(s) for these merges. As we merge the doctor data, we will be making guesses about what a particular field in a file download means? To what degree should we expose those guesses?

How do we merge data sources that will have overlapping and potentially redundant data sources (like addresses for doctors that come from five different files)? How do we handle metadata, when so much of the metadata involves which file/state a data point originated from? Some people will really want to know that, but most people want a slim data structure that is easy to work with.

I feel somewhat uneasy just asking the community of data scientists about these issues, but it ends up being a pretty big deal in the long run. We hope to maintain this as an open dataset, which means that we want people to be able to rely on these file formatting decisions for as long as possible (we will be versioning the format) . Eventually people will start to merge this dataset with DNA and phonemic data, including geo-aware population health data. That is going to be a pretty complicated process and I really want to save headaches for the people involved in this kind of work.

Also important is the size of this dataset. The core data file is an almost 5 GB CSV file. I expect the state files to be around a 1 GB each. Add all of that up and add JSON/XML formatting and you are talking about a lot of space. How can we chose a format that will make working with this dataset easier? So far, we have seen lots of cool stuff because we kept things simple for data scientists.

I would like to open the floor to comments (on this blog post), which the DocGraph project will be taking very seriously. When you comment, if you could mention other “open projects that have solved similar problems and how they did it, that would be great. It would also be great to have links to any relevant SQL or document-based layout standards that might help us. If you are going to provide an academic reference, please also let us know if you have any experience working with those standards. While we really want to solve this problem in a parsimonious way, we do have practical usability as our primary aim here. Thanks for your help in advance.

Related:

• DocGraph: Open social doctor data

The DocGraph dataset shows how doctors, hospitals, laboratories and other health care providers team together to treat Medicare patients. This data details how the health care system in the U.S. delivers care.

You can read about the basics of this data release, and you can read about my motivations for making the release. Most importantly, you can still participate in our efforts to crowdfund improvements to this dataset. We have already far surpassed our original $15,000 goal, but you can still get early and exclusive access to the data for a few more days. Once the crowdfunding has ended, the price will go up substantially.

This article will focus on this data from a technical perspective.

In a few days, the crowdfunding (hosted by Medstartr) will be over, and I will be delivering this social graph to all of the participants. We are offering a ransom license that we are calling “Open Source Eventually,” so participants in the crowdfunding will get exclusive access to the data for a full six months before the license to this dataset automatically converts to a Creative Commons license. The same data is available under a proprietary-friendly license for more money. For all of these “releases,” this article will be the go-to source for technical details about the specific contents of the file.

DocGraph is very likely the largest open and real-named Social Graph of any kind. There are almost 1 million entities that appear in the 2011 data. Each of these entities is either a specific person or organization that provides health care services to Medicare patients. Of course, the graphs found in the Facebook, Zynga, Twitter and LinkedIn datasets are far more expansive, but they are also the closely held property of those companies. When other organizations interact with those graphs, they are given access to only slivers of the whole dataset. If you are not an employee of one of the previously named companies, this is probably the largest named graph that you will have access to. (Let me know if you know of a real-named graph dataset that is bigger …)

This data is keyed using the National Provider Identifier (NPI). This is a universal identifier for doctors and hospitals and was mandated for the purpose of medical billing by HIPAA as replacement to the UPIN system. (HIPAA did a lot of administrative things beyond patient privacy regulations). Anyone who bills Medicare, or prescribes medication, must have an NPI number. The release and adoption of the NPI was an important component of health care reform in its own right, since the NPI was intended to ensure that doctors had only one identifier rather than maintaining a separate identifier for each insurance company that they billed. This number is basically the equivalent of a social security number for doctors. It would be fairly difficult for a health care provider to provide care without one, and as a result they are fairly ubiquitous. I have been working on NPI data for years, at the prompting of the folks from NPIdentify. It is a rich and messy dataset all on its own!

The core NPI database is already an open dataset. You can use the government’s NPI search tool, but it sucks. So I built a better one. If you are a health care provider, you can update your NPI record here. This is a good time to remind doctors that it is a bad idea to list your home address in the NPI data. Because the entire NPI database is public information, and you can download the core NPI release file here. For years the NPI database was updated on a monthly basis, but now it is updated weekly.

The DocGraph dataset is fairly large, with exactly 49,685,586 pairs of referring parties. Of course, even with this many links, the actual dataset that I will be providing is relatively small. The 2011 file is 1.3 GB, which includes about 1 million providers participating in the graph at least once. To provide context, there are about 3.7 million entries in the core NPI file.

I sometimes call the DocGraph dataset the “referral” dataset, and interactions that are traditionally understood as referral relationships make up the bulk of the data. But strictly speaking the data should be considered a “teaming” dataset, which shows when providers work on the same group of patients within the same time frame. I frequently refer to these teaming relationships as “referrals” because A. they usually are referrals, and B. this is easier to say than “participating in the same teaming coupling instance.”

Specifically, the data represents the number of times that two providers billed Medicare for the same patient within a sliding 30-day window, where at least 11 patients were involved in the transaction. If Provider A sees a patient on January 15, and Provider B sees the same patient on February 15, then that counts as “+1.”

In order to ensure that this dataset did not provide any data about patients, we enforce minimum number of patients involved in a given teaming relationship. So for every entry in this dataset, at least 11 patients (which is a standard for CMS somewhere) are involved. This is intended to address the Elvis problem. Everyone knows who Elvis’ doctor is and everyone knows that Elvis is that doctor’s only patient. Therefore, if Elvis’ doctor is “referring” to a cardiologist in this dataset, then everyone would know that Elvis has heart problems. This problem goes away once you include a minimum number of patients in a transaction, so 11 patients is the floor. So we know that at least 11 patients took part in any given “referral count.” Because the patient data is both de-identified and aggregated, there should be no patient privacy concerns in this dataset. (Do let me know if you find evidence that I am wrong about this.)

To further protect patient privacy we cannot tell anything about the number of patients involved beyond the fact that there were at least 11 involved in a given provider-provider relationship. If the same patient sees Doctor A on January 15, Doctor B on February 15 and then again on June 15 and July 15, then that counts as “2″ referrals in this dataset. When a referral relationship has a score of 1,100 we cannot know if this was 11 patients with 100 referral instances, or 1,100 patients with 1 referral instance, or 10 patients with 10 referral instances and 1 patient with 1,090 referral instances. The whole point here is that we have a score that approximates the strength of the relationship between two entities in the NPI database, and for that purpose it does not really matter what kind of patient flow is being indicated.

Entries in the DocGraph dataset take the form

1112223334,5556667778,1100

Where the first number is the NPI of the entity that saw the patient first in time, and the second number is the NPI of the entity that saw the patient the second in time, and the score is the number of times this happend in a 30-day period within a given (2011) year.

I have uploaded the entire referral graph for the Methodist Hospital in Houston, Texas to Pastebin as an example of what you can find in the larger file.

Usually, patients go see a primary care doctor and then get referred to specialists. Usually this translates to the primary care doctor being seen first between the two doctors. But frequently a specialist will be seen and then a patient will return to a primary care provider. In fact, it might be possible to use the relative “directionality” of the graph to automatically guess which provider was the primary care provider and which was the specialist. For instance, given:

1112223334,5556667778,100

5556667778,1112223334,50

It might be reasonable to assume that 1112223334 was a primary care provider.

Doctor and organization types

Beyond just being a “wide” graph with lots of nodes with real-named entities, this dataset is incredibly deep. It is deep because the core NPI public release file contains a tremendous amount of detailed information, which is usually even right!

The first thing that the NPI file contains is at least one and possibly many different types of provider-type taxonomy. These provider types are coded in a provider ontology maintained by the American Medical Association’s National Uniform Claim Committee (I would like to thank the members for performing in this usually thankless task. Committee participation gives me a headache.) You can download this Health Care Provider Taxonomy, or you can browse it online.

The good news here is that the NPI database uses a provider-type taxonomy. However, there is little justification that this should be a “tree” style taxonomy. The assumption in a hierarchical taxonomy is that leaves can only have one “parent.” This means that a given “doctor type” can be either listed under the “cardiology” group or the “pediatrics group,” but not both. As a result there a lots of very arbitrary groupings for doctor types here. Doctors cannot find a sensible way to navigate this “tree” style taxonomy when they sign up. Since they have to choose something, they usually get at least one “type” correct, but often, this database does not correctly represent the breadth of a given doctor’s actual specializations.

Still, it is a good assumption that the provider taxonomy field in the core NPI file is usually correct, and as a result, it is possible to distinguish effectively between hospitals, primary care doctors, specialists types, and laboratories in the referral dataset. In fact, one of the most frequent “referrals” in the data is the referral to get lab work done at LabCorp, Quest or one of the local lab providers. Referrals to hospital emergency departments (which are not referrals at all, of course) and treatment facilities like DaVita are also very common. I have uploaded the top 100 organizations by the number of entries that they have in the dataset to Pastebin so that you can clearly see the types of relationships that will be most common in the data.

Geocoding

The core NPI database also contains two addresses for each NPI record, the practice location address and a mailing address. I have done queries against the Open Street Map database and about 80% of the addresses are already coded to latitude or longitude. There are zip codes that can be used to detect general location for the other 20%.

This means that is going to be possible to run all kinds of geo-data queries against this dataset. There are all kinds of other geo databases that can be overlaid against this referral database in order to reach interesting conclusions. You could easily, for instance, study referrals to allergy doctors in relationship to geo-recorded air quality scores. Let me know if you make some pretty maps and I will try to give you a shout out on Twitter or on my blog.

Hospital data

Quality and performance data for individual doctors is pretty hard to come by. However, there has been an explosion in the availability of hospital data that details how hospitals perform on critical issues like readmission rates and central line infection rates. Frequently this quality data is coded natively using NPIs and it is usually pretty simple to convert this data to NPI coded when the NPI is not directly available.

This hospital data will be part of what we are trying to merge together for our improved DocGraph project.

There are lots of interesting questions that you can ask regarding this dataset. For instance, using the DocGraph, you can determine which cardiologists are referring to hospitals with poor central line infection rates.

State level credentialing data

Every state has a state level medical board that releases data on individual doctors. This data usually includes what medical school a doctor attended, what board certifications they maintain, and any disciplinary actions that the state board has undertaken against this doctor. Unfortunately this data is expensive between ($50 and $500 per state) and rarely coded using an NPI.

This is the largest single disconnected data source from the current NPI database. Buying and normalizing this data is the first goal of our Next Level crowdfunding effort.

Using this data it would be simple to determine if attending the same medical school was an important part of how doctors refer. It will also be possible to determine if board certification has an impact on referral patterns.

Non-profit data

I have just discovered through BoingBoing that resource.org will be performing data extraction on its enormous cache of non-profit tax filings. Once it is possible to import this as a data source, it should be possible to figure out what the NPI for different non-profit hospital systems are. Once this is done, it would be possible to see how executive compensation works with the graph. This is not something we will be doing with our initial improvement project, but this is obviously where we would like to take this!

Limitations

As with all rich datasets, this data is convoluted and can be confusing. Already we have seen patterns that do not make sense unless you understand how the data was built. This is based on administrative data and not clinical data. So this shows not how patients were “treated” together, but how they were “billed” together. There are several important artifacts to consider as the result of this.

First, individual providers frequently have two NPIs in the database. One for them as an individual and another for an organization that exists only for that individual. Seeing an NPI for “Dr. Smith” and another for “Dr. Smith, LLC” is not uncommon. As a result of this, frequently a given provider will not even appear in the DocGraph at all. Some digging is often required to determine how a given doctor is actually interacting with Medicare. Frequently, when an individual NPI and organizational NPI share an address, this means they are working as one unit.

Sometimes, it is the organization that is hidden in the billing. We have already seen cases where a given primary care provider is referring to more than 20 different cardiologists. A little further digging shows that these cardiologists are all part of a cardiology service. Obviously the primary care doctor is referring to the cardiology service, and does not actually have relationships with the individual cardiologists. However, there is no way, using just the DocGraph, to tell the difference between a “service” where doctors bill as individuals and a group of unaffiliated doctors.

There are cases where cardiologists list themselves as cardiac surgeons in the NPI database and vice versa. Doctors frequently rely on administrative staff members to fill out the data in the NPI database, and they often get it wrong. This issue impacts the quality of addresses and countless other issues. The current NPI registration form attempts to normalize addresses, but the older forms did not. Keep in mind that this data is just as subject to user entry errors as anything else.

In many cities, a given hospital will win the contract for the main emergency room. This often makes it seem like every provider in the city has a “referral” relationship with that hospital. Of course, this is not strictly true. A good sign is if an organization has a strong “referral” relationship with the local fire department, then they run the local emergency room and there “team” with every doctor in the city.

Because Medicare typically covers people over the age of 65, there is not very much information about doctors who exclusively treat children, or women who are having children. This means that there is a lack of data about pediatrics or ob/gyn doctors. There is also no information on doctors who do not take Medicare patients. Also there is no data in this dataset for providers who do not bill Medicare in a transactional fashion. Fully capitated plans like Kaiser Permanente will not have data in this dataset. If you put this data on a map, there should be a big hole over southern California as a result of this.

This dataset, like any messy data, should not be considered the “truth” but it can be used to help generate and reject hypotheses about how a given community delivers health care. We have lots of ideas about how to make the data more reliable and more accessible, but in order to do that, we need your help paying for improvements to the data. Even if you do not yourself want to have access to richer data, consider supporting us as we provide data for those who wish to have access to high quality versions of open doctor data. This dataset should deliver on the overall promise of open data: transparency improves performance.

There is a DocGraph Google Group now, that you can join if you would like to ask specific questions about this dataset.

Strata Conference Santa Clara— Strata Conference Santa Clara, being held Feb. 26-28, 2013 in California, gives you the skills, tools, and technologies you need to make data work today.Save 20% on registration with the code STRATA20

Related:

• When data disrupts health care
• Solving the Wanamaker problem for health care

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

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.

Related:

• Principles of patient access in Directed Exchange
• The truth about data: Once it’s out there, it’s hard to control
• Why geeks should care about meaningful use and ACOs
• See more of Radar’s health IT coverage

Sadly, the “letter of the law” in HIPAA is frequently either ignored or worse, fully embraced, in order to make patient access to their own healthcare data more cumbersome. This is evidenced nowhere better than Regina Holiday’s experience with access to her husband’s medical records. To make a long story short, she was able to acquire an unpublished manuscript of a Stephen King novel, sooner and for less money than she was able to get her husband’s medical records.

Principle zero: Some clinicians will do anything they can to make patient access to their health records impossible or cumbersome.

Regina’s work, detailing her experience with her husband is titled 73 cents, because that’s how much it cost to get one page of her husband’s medical record. HIPAA allows hospitals and clinicians to charge a “reasonable” copying fee for access to patient records. The problem with that is that in the digital age, a single healthcare record print out looks like this:

A partial printout of a patient’s medical record.

This is what happens when you print out a digital health record. Having patients pay the copying costs for access to medical records makes a simple presumption: there are only a few pages there. Obviously no patient will be able to afford copying costs in the age of all-digital records.

Principle one: Patient access to their own healthcare records must be digital once the record is digital.

Once you concede that access to the patient’s medical record must be digital, we can discuss the push vs. pull question. When someone else on the Internet has data that is important to you, you can generally find ways to have it “pushed” to you or you can choose to “pull” it. The simplest example is the weather. You can always check the weather easily online by visiting a website (by pulling). But you can also have software text you when it is going to rain (by pushing).

There are advantages of both push and pull approaches for patient access to data. People who are excited about the pull model tend to focus on the benefits of the “portal” requirements in Meaningful Use, and those that favor the push model are excited about directed exchange. Without getting into the debate, I can posit that there are some cases where push access to patient data is critical. Without supporting patient participation in directed exchange we regulate patients to second-class citizens with regard to healthcare exchange.
That is unacceptable. Patients should be first-class citizens in healthcare exchange.

Principle two: Patients should be able to participate in health information exchange as first-class citizens.

The Office of the National Coordinator for Health Information Technology (ONC) should be applauded for requiring directed exchange with patients in the current proposed rule. I hope that ONC does not back off of this new requirement.

The current proposed rule making, however, is silent on a critical issue for directed health information exchange. How do we ensure that providers will not refuse to communicate with patients over directed exchange because of bogus “security concerns”? As we see with the copying costs under HIPAA, every potential barrier to a patient’s access to data will be used against patients.

There are already rumors of cases in the pilots of directed exchange where organizations are using the trust architecture of the Direct Project to refuse to communicate with certain parties. While that might be reasonable between institutions (do you really think Planned Parenthood will ever automate communication with Catholic charity clinics or vice-versa?), it is absolutely critical that this not hamper patient-clinician communication.

When we first designed the Direct Project Trust model, we presumed that patient-clinicians communication would take place based on “business-card” identity verification. That meant that when a patient provided a clinician with a public key (no matter how they did that) the clinician would trust it because the patient provided the public key. We did this because we knew that if clinicians could reject a patient’s public key based on “security concerns,” they would do so. Either the clinicians (or more likely the vendors that they hired) would choose directed exchange “partners” that were “approved” and “secure,” ensuring that the patient’s experience of directed exchange was merely a more extensive menu of patient portal options. Patient data is very valuable and controlling the flow of patient data is central to more business plans than I care to count.

In order for patients to be first-class citizens in health information exchange, they should have the right to send their records, in an automated fashion, anywhere they want. Even if it meant sending it to a service that the patient was enthusiastic about, but the clinician disapproved of (i.e. qpid.me). In the world of secure email enabled by public-key infrastructure (PKI), that translates to clinicians must accept any public key/direct address presented by a patient in a reasonable manner. This acceptance must be unconditional, but should probably mean limiting the acceptance of that key to communication with just that patient. Anything less than this means that the patient is a second-class citizen with regards to the information exchange of their own data.

Conclusion: ONC should require that clinicians communicate with a patient’s chosen directed exchange provider, which means accepting any public key presented by a patient in a reasonable manner.

The community at Direct Trust is working hard to agree on what “reasonable manner” should mean, exactly. Here is my latest proposal on the subject, and here are similar ideas from Dr. David Kibbe. Eventually the Direct Trust community will knock out a firm understanding on the specific ways that might be “reasonable” for a patient to provide a certificate. But we are certainly agreed that without firm requirements on certificate acceptance, this issue will be used by clinicians to limit where patients can send their own data.

As the U.S. federal government is preparing to pay healthcare providers to adopt electronic health records (EHR) they will insist that those doctors/hospitals/etc. show that they are using the new software in clinically meaningful ways. On Monday (May 7, 2012) they will be accepting comments on the second stage of the requirements that clinicians must meet in order to receive compensation. These requirements are usually short-handed as “meaningful use.”

I will be submitting this blog post as my comments to that process. Others will be submitting comments that directly contradict the principles and conclusions I write here. Most notably the American Hospital Association (AHA) has argued that the requirements for patient portals and for providing patients with access to their digital record should be entirely removed from the meaningful use standards (PDF). Specifically:

“Our members are particularly concerned with the proposed objective to provide patients with the ability to view, download and transmit large volumes of protected health information via the Internet (a “patient portal”). The AHA believes that this objective is not feasible as proposed, raises significant security issues, and goes well beyond current technical capacity. We also believe that CMS should not include this objective because the Office of Civil Rights, and not CMS, regulates how health care providers and other covered entities fulfill their obligations under the Health Insurance Portability and Accountability Act (HIPAA), including the obligation to give patients access to their health records.”

This is fairly ironic, since the report also says:

“To date, OCR has received comments on its own significantly
flawed original proposal to implement this section of HITECH, but has yet to finalize the
standard.”

Apparently, AHA is not satisfied with any government agency’s interpretation of giving electronic access to patient data. The AHA would prefer that patients continue to wait the same amount of time for access to their digital records that they do for their paper records. Specifically:

“Further, 30 days are necessary to make determinations about how to respond to a request no matter the format of the protected health information. While providing an electronic copy of protected health information maintained in an EHR eventually may be facilitated more easily by technology, the process of determining which records are relevant and appropriate takes the same amount of time as it does for evaluating paper records.”

Of course, this is entirely false. Indeed, HIPAA does maintain that certain parts of healthcare records (i.e. a psychiatrist’s notes) and disclosures (i.e. when the FBI asks for records) are not subject to patient access. An EHR should be capable of understanding which parts of an EHR record are subject to HIPAA and which are not. If the EHR system can understand this distinction, then responses to HIPAA requests can be made in near-real-time. If the EHR system cannot make the distinction between which portions of the record to automatically provide to honor a HIPAA patient access request, then having 30 days is not going to be enough. Can you imagine a nurse reading through the entire stack of papers above to ensure that a certain mental health diagnosis is redacted?

One of the most critical features of patient participation in directed exchange is the patient’s capacity to prevent the spread of bad information as it is happening. Apparently, the AHA believes that patients should tolerate the spread of mis-information in their health records to other institutions for a month before correcting it. This of course works in every situation where patients can wait a whole month to get correct information to other hospitals and clinicians.

I would like to be the first to welcome the American Hospital Association to the digital age. (Okay, maybe the second.) From a technology perspective, there is nothing at all that would prevent patients from receiving copies of their updated digital health records seconds after it is “signed” by their clinicians. Inside those seconds is plenty of time to digitally determine whether sharing with the patient is appropriate, legal and safe. Seconds after a patient like me receives data, I intend to process it in an automated fashion. It is not unreasonable, in this new digital world, for me to get a text message that a doctor has ordered a medication that I am allergic to. I wish to get that message after the doctor has ordered the medication, but before I receive it in my IV.

In this new digital world, 36 hours is unreasonable. It means that humans continue to be involved in tasks that can be performed perfectly by a computer without errors. Even 36 hours means that doctors, nurses and hospital administrators are still “thinking in paper.” Thirty-six hours means that you still do not view me, the patient, as an equal data partner. It means that I am blind to the data in your hospital at the only time it really matters, which is right now. Health data that is 36-hours old can only be analyzed as a post-mortem and data that is 30-days old is already rotting. As a patient, 36 hours is a short-term solution. It is an opportunity for you to rethink how information flows in your hospitals. It is an opportunity for you to rethink the notions of “inside” the hospital and “outside” the hospital.

This is not that I do not take your point regarding the reconciliation of the policies from the perspective of HIPAA and meaningful use. Two time-lines for compliance is difficult. But the reconciliation is to speed HIPAA up, not slow meaningful use down. The notion that you will give patients a stack of paper like the one above 30 days after it is useful is a bad joke. It was a bad joke 20 years ago, when the technologies already existed to fix the problem, but you decided that the patient’s experience was not worth that investment.

There is always something you can do, if you feel as strongly about this as I do.

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.

Photo: Medical record printout by jodi0327, on Flickr

Related:

• The state of health IT according to the American Hospital Association
• The Direct Project: Healthcare communication gets an upgrade
• Epatients: The hackers of the healthcare world
• Building the health information infrastructure for the modern epatient
• Why geeks should care about meaningful use and ACOs
• See more of Radar’s health IT coverage

Jim Langabeer is the CEO of the newly renamed Greater Houston Healthconnect. I caught up with Jim at Starbucks and peppered him with questions about where Health Information Exchange (HIE) is going and what HIE looks like in Houston.

What’s your background?

Jim Langabeer: I have been in healthcare for a long time in the Texas Medical Center.  I started as a hospital administrator at UTMB, where my first project was to work on an IT project team developing a Human Resources Management System. It was a collaborative effort between three hospitals.

I recently led a software company in the business intelligence space, which was later acquired by Oracle. After that, I decided I wanted to come back to Houston and continue to work in healthcare, so I returned to work for MD Anderson leading project and performance management. I eventually worked with the CIO Lynn Vogel to assess the business value of information systems. I most recently taught healthcare administration at the UT School of Public Health.

Throughout my healthcare career, I have been using data to drive healthcare decisions. My PhD is in decision sciences — quantitative modeling of data for decision-making — and my research grants have all involved analyzing large datasets to make healthcare decisions better. I have also worked between organizations in a collaborative manner. Health Information Exchange was an obvious next step for me.

Where are you in the process of creating a health information exchange?

Jim Langabeer: We are in the middle stage of operations. We are finalizing our architectural vision and choosing vendors. Most importantly, we have strong community support: 41% of the doctors in the region have committed to the exchange with letters of support as well as 61 of the 117 local hospitals.

We are meeting with all of the doctors we can. We are calling them and faxing them and visiting them, with one simple message: Health IT is coming and we want you to participate.

You mentioned an “architectural vision.” Can you expand on that?

Jim Langabeer: We really cannot have just one architecture, so our architectural vision really means choosing several protocols and architectures to support the various needs of our stakeholders in parallel. We need to accommodate the entire range of transactions that our physicians and hospitals perform. The numbers say that 50% of Houston docs work in small practices with only one or two doctors, and they typically do not have electronic health records (EHR). Hooking these doctors into a central hub model does not make sense, so a different model where they can use browser/view capabilities and direct connections between providers must be part of our architectural vision.

Houston also has several large hospitals using EPIC or other mature EHR systems. That means we need a range of solutions. Some docs just want to be able to share records. Some are more sophisticated and want to do full EHR linking. Some doctors just want to be able to view data on the exchange using a web portal.

We want to accommodate all of these requests. That means we want a portfolio of products and a flexible overall architectural vision. Practically, that means we will be supporting Direct, IHE and also older Hl7 v2.

Some people are saying Direct is all we want. We do not want a solution that is way over what small providers can handle and then it never gets used. We are architecture- and vendor-neutral, which can be difficult because EPIC is so prevalent in Houston.

We have practices that are still on paper on one hand and very sophisticated hospitals on the other, and that is just in the central Houston area. Immediately outside of Houston, lots of rural hospitals that we plan to support have older EHR systems or home-grown systems. That means we have to work with just about every potential health IT situation and still provide value.

Recently, a JAMIA perspectives article criticized Direct as a threat to non-profit HIE efforts like yours. Do you feel that Direct is a threat?

Jim Langabeer: I do not see Direct as a threat. I hear that from lots of sources, that Direct is a distraction for health information exchanges. I disagree.

I see it as another offering. The market is obviously responding to Direct. The price point on the software for Direct is definitely a benefit to smaller docs. We see it as a parallel path.

We do not see Surescripts (which is offering Direct email addresses to doctors with the AAFP) as a threat because we see them as a collaborator. We want them, and similar companies, to be part of our network. We are also having conversations with insurance companies and others who are not typically involved in health information exchanges because we are looking for partners.

The problem in healthcare is that it has always been very fragmented; no single solution gets much penetration. So, as we consider different protocols, we have to go with what people are asking for and what is already being adopted. We have to get to a point were these technologies have a very high penetration rate.

How are you narrowing your health IT vendors?

Jim Langabeer: What we want is a vendor that is going to be with us long term, sharing our risks and making sure we are successful. The sustainability of the vendor is connected to the sustainability of our exchange, so that is really important. Our 20-county region represents 6.4 million people, and that population is larger than most states that are pursing exchanges. Not many vendors have experience on that scale.

How important is the software licensing? Do open source vendors have an advantage?

Jim Langabeer: I am not sure they have an advantage. Of course, open source is ideal, but often proprietary vendors are ahead in terms of features. A mix in the long-term solution would be really cool.

How will you work with outside EHR vendors?

Jim Langabeer: We are trying to engage at the CIO level. We’re trying to understand what solutions standards and data they want to share. There is a core set of things everyone needs to do. Beyond that core, some people want to go with SOA; other people really want IHE or Direct. There is not much data sharing between hospitals. That is why industry standards are so important to us. It helps us shorten those discussions and make a more narrow offering. So, we are focusing on protocols as a means to work with the various EHR vendors.

One CIO told us, “We do not want to exchange data at all; we just want our doctors to be able to open a browser and see your data.” We may not like to hear that, but that is the reality for many organizations in Houston.

The other thing that is unique about Houston is that you are not going to see the state of Texas taking a dictatorial role. In other large exchanges, you often have a state-level government dictating HIE. In that environment, it is easier to insist on specific standards. That is not our situation in Houston, so we have to meet our constituents where they are.

I have been frustrated that the Direct Project reference implementations only come in Java and .NET at this point. I would like to see implementations in PHP, Python, Ruby, etc. — languages that are more popular with entrepreneurs. Are you concerned with issues like that?

Jim Langabeer: We’re definitely thinking about things like that. We do not want to be merely business-to-business — we want to offer services to consumers. So, we care about the technology becoming accessible to consumers, which means getting to iPhones. We want to be able to offer consumers tools that will bring them value, so we certainly care about issues like implementation language because we see those issues as connected.

If I let you dictate which Houston clinic or hospital I go to, when can I go see a doctor and get my patient data sent to my HealthVault or other PHR Direct account?

Jim Langabeer: I would hope that the technology would be ready by the end of year. What I envision is a core group of early adopters. We already have several hospitals and some physician groups that are interested in taking that role.

This interview was edited and condensed.

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.

Related:

• The Direct Project: Healthcare communication gets an upgrade
• Epatients: The hackers of the healthcare world
• Building the health information infrastructure for the modern epatient
• Why geeks should care about meaningful use and ACOs
• See more of Radar’s health IT coverage

Let me concede and endorse his main point that doctors will become bionic clinicians by teaming with smart algorithms. He is also right that eventually the best doctors will be artificial intelligence (AI) systems — software minds rather than human minds.

That said, I disagree with Khosla on almost all of the details. Khosla has accidentally embraced a perspective that too many engineers and software guys bring to health IT.

Bear with me — I am the guy trying to write the “House M.D.” AI algorithms that Khosla wants. It’s harder than he thinks because of two main problems that he’s not considering: The search space problem and the good data problem.

The search space problem

Any person even reasonably informed about AI knows about Go, an ancient game with simple rules. Those simple rules hide the fact that Go is a very complex game indeed. For a computer, it is much harder to play than chess.

Almost since the dawn of computing, chess was regarded as something that required intelligence and was therefore a good test of AI. In 1997, the world chess champion was beaten by a computer. In the year after, a professional Go player beat the best Go software in the world with a 25 stone handicap. Artificial intelligence experts study Go carefully precisely because it is so hard for computers. The approach that computers take toward being smart — thinking of lots of options really fast — stops working when the number of options skyrockets, and the number of potentially right answers also becomes enormous. Most significantly, Go can always be made more computationally difficult by simply expanding the board.

Make no mistake, the diagnosis and treatment of human illness is like Go. It’s not like chess. Khosla is making a classic AI mistake, presuming that because he can discern the rules easily, it means the game is simple. Chess has far more complex rules than Go, but it ends up being a simpler game for computers to play.

To be great at Go, software must learn to ignore possibilities, rather than searching through them. In short, it must develop “Go instincts.” The same is true for any software that could claim to be a diagnostician.

How can you tell when software diagnosticians are having search problems? When they cannot tell the difference between all of the “right” answers to a particular problem. The average doctor does not need to be told “could it be Zebra Fever?” by a computer that cannot tell that it should have ignored any zebra-related possibilities because it is not physically located in Africa. (No zebras were harmed in the writing of this article, and I do not believe there is a real disease called Zebra Fever.)

The good data problem

The second problem is the good data problem, which is what I spend most of my time working on.

Almost every time I get over-excited about the Direct Project or other health data exchange progress, my co-author David Uhlman brings me back to earth:

What good is it to have your lab results transferred from hospital A to hospital B using secure SMTP and XML? They are going to re-do the labs anyway because they don’t trust the other lab.

While I still have hope for health information exchange in the long term, David is right in the short term. Healthcare data is not remotely solid or trustworthy. A good majority of the time, it is total crap. The reason that doctors insist on having labs done locally is not because they don’t trust the competitor’s lab; it’s more of a “devil that you know” effect. They do not trust their own labs either, but they have a better understanding of how and when their own labs screw up. That is not a good environment for medical AI to blossom.

The simple reality is that doctors have good reason to be dubious about the contents of an EHR record. For lots of reasons, not the least of which is that the codes they are potentially entering there are not diagnostically helpful or valid.

Non-healthcare geeks presume that the dictionaries and ontologies used to encode healthcare data are automatically valid. But in fact, the best assumption is that ontologies consistently lead to dangerous diagnostic practices, as they shepherd clinicians into choosing a label for a condition rather than a true diagnosis. Once a patient’s chart has a given label, either for diagnosis or for treatment, it can be very difficult to reassess that patient effectively. There is even a name for this problem: clinical inertia. Clinical inertia is an issue with or without computer software involved, but it is very easy for an ontology of diseases and treatments to make clinical inertia worse. The fact is, medical ontologies must be constantly policed to ensure that they do not make things worse, rather then better.

It simply does not matter how good the AI algorithm is if your healthcare data is both incorrect and described with a faulty healthcare ontology. My personal experiences with health data on a wide scale? It’s like having a conversation with a habitual liar who has a speech impediment.

So Khosla is not “wrong” per-se; he’s just focused on solving the wrong parts of the problem. As a result, his estimations of when certain things will happen are pretty far off.

I believe that we will not have really good diagnostic software until after the singularity and until after we can ensure that healthcare data is reliable. I actually spend most of my time on the second problem, which is really a sociological problem rather then a technology problem.

Imagine if we had a “House AI” before we were able to feed it reliable data? Ironically it would be very much like the character on TV: constantly annoyed that everyone around him keeps screwing up and getting in his way.

Anyone who has seen the show knows that the House character is constantly trying to convince the other characters that the patients are lying. The reality is that the best diagnosticians typically assume that the chart is lying before they assume that the patient is lying. With notable exceptions, the typical patient is highly motivated to get a good diagnosis and is, therefore, honest. The chart, on the other hand, be it paper or digital, has no motivation whatsoever, and it will happily mix in false lab reports and record inane diagnoses from previous visits.

The average doctor doubts the patient chart but trusts the patient story. For the foreseeable future, that is going to work much better than an algorithmically focused approach.

Eventually, Khosla’s version of the future (which is typical of forward-thinking geeks in health IT) will certainly happen, but I think it is still 30 years away. The technology will be ready far earlier. Our screwed up incentive systems and backward corporate politics will be holding us back. I hardly have to make this argument, however, since Hugo Campos recently made it so well.

Eventually, people will get better care from AI. For now, we should keep the algorithms focused on the data that we know is good and keep the doctors focused on the patients. We should be worried about making patient data accurate and reliable.

I promise you we will have the AI problem finished long before we have healthcare data that is reliable enough to train it.

Until that happens, imagine how Watson would have performed on “Jeopardy” if it had been trained on “Lord of the Rings” and “The Cat in the Hat” instead of encyclopedias. Until we have healthcare data that is more reliable than “The Cat in the Hat,” I will keep my doctor, and you can keep your algorithms, thank you very much.

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.

Related:

• Software crumple zones
• Why geeks should care about meaningful use and ACOs
• Why developers should enter health IT contests
• Epatients: The hackers of the healthcare world

Quantify what you want to change about yourself + motivational hacks = personal change success.

There are several potential “motivation hacks” that people regularly employ. The simplest of these is peer pressure. You could tell all of your co-workers every morning whether you kept your diet last night, for instance. Lots of research has shown that sort of thing is an effective motivator for change. Of course, you can make peer pressure digital by doing the same thing on Facebook/Twitter/Google+/whatever. Peer pressure has two components: shame and praise. It’s motivating to avoid shame and to get praise. Do it because of a tweet and viola, you have digital peer pressure motivation.

Several books have recently popularized using money, in one form or another, as a motivational tool. There is some evidence, for instance, that people feel worse about losing $10 than they feel good about earning $10. This is called loss aversion, and it can easily be turned into a motivational hack. Having trouble finishing that book? Give 10 envelopes with $100 each to your best friend. Instruct them to mail the envelopes to your favorite (or most hated) charity for each month that you do not finish a chapter. Essentially, you’ve made your friend a “referee” of your motivational hack.

So, is there any potential to automate this process? To use software to hack your own motivation? One of the coolest applications that does just that is StickK.com, which is designed to electronically manage contracts you make with yourself.

But that, by itself, is not programmable self.

Programmable self is the combination of a digital motivation hack, like StickK, with a digital system that tracks behavior, like Fitbit (that’s the Quantified Self part). You have to have both. Recently, for example, Stickk started supporting the use of the Withings Scale to support weight entries. Withings is a Wi-Fi-enabled scale that broadcasts your weight automagically to the Withings servers. From there, Withings will send your weight generally wherever you want: HealthVault, other personal health record (PHR) systems, or over to Stickk.com. With that feature, Stickk became a programmable-self platform.

Stickk is pretty old, and Lose it or Lose It, which is focused specifically on losing weight, is also ancient in Internet time. It launched in 2009. The site requires you to take a picture of a weekly weigh in (you actually photograph the scale) and send it in. That counts as digital tracking, but I wonder if it supports Withings (or if it will).

In October 2011, Beeminder launched, billing itself as a direct Stickk competitor, but “for data geeks.” Indeed, it is a little geeky: Beeminder is focused on weight change and other goals that are numerically similar to weight change. The notion is that there is a proper path for the improvement of certain numbers — as well as a little “data jitter” to eliminate — in order to improve. Beeminder also refers to the classical term for the lack of self discipline: akrasia — so bonus points for that.

Last November, The Eatery launched from Massive Health. Massive Health is a massively funded dream team, and their first app is a classic programmable-self experiment. You simply take pictures of your food with your camera (digital tracking = photos) and let others rate your food choices (motivation hack = praise/shame). It’s a good idea, and you can expect lots more from Massive Health that qualifies as programmable self.

Recently, GymPact made a big splash, even ending up in a New York Times blog post. Gympact is an iOS (soon Android) app that lets you check in at the gym. If you fail to check in, you get charged a fee. If you do keep your commitment to go to the gym, then you also earn some of the money from all of the people who failed to go to the gym.

Finally, Buster Benson and Jen S. McCabe are working on Bud.ge, which might be the first of the programmable-self platform plays.

All of these count as programmable self. I seriously doubt that any of these companies were aware of my original interview about programmable self or would even be comfortable with the term, which sounds pretty geeky and devious. (Which is, of course, why I love it.)

Other friends of mine in the serious games/games for health/gamification movement would probably count as programmable self, too. But some of them seem convinced that “fun” can have a deeper component in motivation than some of the more aggressive techniques that I, and other programmable self people, seem to favor. I should also mention that I am hardly the only one in the QS movement stumbling in this direction.

I will be writing about programmable self on Radar occasionally, but there is a lot more going on than I can track here . That’s why I’ve also made a Tumblr about the subject and filled it with all of the “software for behavior change” goodness that anyone can take. My @fredtrotter Twitter account is mostly focused on programmable self as well.

Most importantly, I want to hear about what you have tried to do with your own personal change hacks, especially those that impact your health in one way or another. For that, I have set up a Programmable Self Google Group. Please join us. Some of the top minds in behavior change are already subscribers.

The Quantified Self movement is not primarily about the “tool creators” who make stuff for people to use, but a movement of users who defy the boundaries of tools and manage to create innovative quantification tools on their own. Many of these efforts also count as programmable-self approaches. No discussion of programmable self can ignore the work of individuals, so here is a decidedly non-exhaustive list of people innovating in this space:

• Amelia Greenhall: Weigh Everyday = Understanding
• Nick Crocker: Floss the Teeth You Want To Keep
• Nancy Dougherty on Mindfulness Pills

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 “e” in epatient is intentionally obscure. The initial assumption is that the “e” stands for “electronic,” as it does in “email.” But in fact, the “e” stands for “engaged” or “empowered.” Nonetheless, reference to email is intentional: The epatient community recognizes that leveraging data is a critical part of empowering a person who happens to be sick. Patients must be “electronic” to become fully “engaged.” I think of epatients as the healthcare equivalent of makers and hackers. More importantly, they are the people I have in mind when I write software.

Engaged patients get better healthcare. Not just a little bit better. Much better. This is not a thesis I am prepared to defend here, except to drop a link to the Journal of Participatory Medicine, which is a good resource for those seeking a full chronicle of this engaged effect (the benefits of engagement have been documented in the healthcare literature for years).

Let’s go over some simple concepts that the rest of my epatient advice and resources are based on:

• Your doctors are probably not managing your healthcare information. You should assume it is your responsibility. Otherwise, the people involved in your treatment process will often presume that this information simply does not exist.
• Other patients, with similar conditions to yours, can have better information about your health problem than your doctors have.
• Like the highway system, the healthcare system is generally beneficial, but there are dangers, and you need to learn to avoid them.

And here are two things you should keep in mind:

• Whenever I say “patient,” I actually mean “the patient/caregiver team.” Often, the patient will not have the energy to do what is necessary to be fully engaged. It is critical that when the patient cannot be an epatient, that at least the patient’s team be an epatient proxy.
• In regard to the “better information” I mentioned above, I don’t mean that your doctor is typically wrong and another patient is typically right about your diagnosis or treatment options. While that does happen on occasion, it is not the norm. Another patient’s information is “better” because your doctor typically does not have the visceral experience of being a patient. Your doctor doesn’t understand which lotion can make all of the difference or what position might let you get some sleep after a rough procedure. There is simply no substitute for experience. Sometimes that experience can make your life a little easier, and sometimes it can help you get the right treatments that literally will save your life. (This is the gist of epatient Dave deBronkart’s story.)

The first thing an epatient needs to do is find the right epatient community. For any common illness or group of symptoms, there is a community of people who are already connecting with each other over the Internet. For people with a recent cancer diagnosis ACOR is probably the right place to start. This is one of the oldest, largest and most active epatient communities. Sometimes, the tools that a particular community of epatients choose might be a little old school — things like traditional forums, or even list-serves. Do not judge a community by its adoption of technology, judge it by its activity level.

There are efforts to create technology solutions that are specifically designed to enable patient communities. For a good example, check out PatientsLikeMe, which is representative of patient communities drifting more toward “patient social media.” I am happy to say that epatient tool makers like me are coming up with cool stuff constantly. But the mature epatient is not impressed by new and shiny. Remember, it is the relationships and insights that matter here, not the technology. Whenever possible, you want the right information delivered over the wrong technology medium, rather than the other way around.

For any serious common healthcare condition, there are probably several different communities of patients online that you can meet with. For common conditions, you might also be able to find a specific meetup in your area, or at least some kind of epatient meetup. If you have a rare disease, you might have trouble finding local resources, and you might only have one or two online communities to choose from. But for rare diseases, the online patient community as a whole is typically better informed than the average primary care physician on a particular condition. Sometimes a physician might not understand or recommend treatment options that are offered outside their local healthcare community, an issue that can be compounded when they are unfamiliar with a particular type of diagnosis. It is even more critical for rare disease patients or caregivers to find a patient community and listen to them. For rare diseases and conditions, it is critical to understand what treatment options are offered in other areas and to be fully informed regarding sham clinics that often operate in under-regulated areas.

How do you know you’ve found the right community? Here’s a good rule of thumb: If you can’t get a real response to a simple health question from the community within 24 hours, you should probably move on if there are other options. Healthy epatient communities are vibrant and alive.

You should also consider joining the Society for Participatory Medicine (SPM). The mailing list for the SPM is one of the most important cross-condition meeting places for epatients.

If you are interested in the technology side, also pay attention to Health 2.0 (#health20), which has a Patients 2.0 (#patients20) community that is concerned with the “electronic” part of epatient. Generally, I find that Health 2.0 is the right place to find out-of-the-box thinking on healthcare information systems, especially those offered directly to consumers. I go there to get the down-low on my competitors and to find collaborators. Matthew Holt from Health 2.0 cross pollinates the healthcare blog, which is also worth adding to your RSS reader.

The cross-disease epatient community uses Twitter more than Facebook or Google+ (for the time being), and the #epatient hashtag is your friend. I also recommend following @epatientdave, @reginaholliday, and @hhask as good starter accounts. If you care about the tech aspects of epatients, then check out @NateOsit or myself (@fredtrotter). And if you’re interested in the activist portion of the epatient community, then look at the Occupy Healthcare roster.

Once your healthcare information gets past a certain basic level of complexity, it becomes important that you have a personal health record (PHR). Your doctors should, eventually, be able to update your PHR. That means you need a PHR that supports the Direct Project. Right now, that is a short list, with Microsoft’s HealthVault at the top. As a FOSS advocate, that is not an endorsement I make lightly, but Microsoft’s health IT team has been surprisingly supportive of open source (i.e. patient empowering) technologies and they have relatively mature Direct support. Indivo is pretty much the only one to consider if you want to run your own PHR (it’s open source), but its Direct support is lagging. Something you should keep in mind: If you have only one doctor at a time, you do not need to obsess about the coordination of your own healthcare information; if you have more than one doctor, you do. You can manage this information with a PHR, or a notebook, or even an infographic. What matters is that you need to do it, and do it carefully.

Some of the people in the Quantified Self movement are patients who are trying to use data about themselves to improve their health. If that interests you (if you have a chronic condition, it should), then take a look at the Quantified Self website.

There are two types of patients: those who are in crisis mode and those who are in maintenance mode. If you are in crisis mode, and you feel like your whole world has been turned upside down, then I recommend you read Dr. Carolyn Oliver’s book “Cautious Care: A Guide for patients.” The newest edition of this book is also available as a series of free PDF downloads from the Cautious Patient Foundation website. Here are direct links to the hospital part and the outpatient part. Dr. Oliver’s book is like a “defensive driving crash course” for the healthcare system. If you are going to be staying up all night at the hospital (as a caregiver or a patient), and you have no idea what you should be paying attention to, this is the book that you should be reading. (Disclosure: I work for Dr. Oliver at the Cautious Patient Foundation.)

If you are in maintenance mode, you should still start with Dr. Oliver’s books, but you can also extend your reading to the classics of the epatient movement. That process should always begin with the e-patient white paper, and I also recommend the book “Laugh, Sing, and Eat Like a Pig” for ethos purposes. Go to e-patients.net and click “categories” to find the content on that blog that seems relevant to you.

If you are well, consider spending some time with these resources. When you become sick you do not want to be learning how this stuff works. You will probably ignore this advice, and that’s fine. Just try to remember that this advice is here when you need it. Also, remember that these are not instructions for how to handle your illness; they’re instructions for finding the instructions on how to handle your illness.

If you are newly sick, then what I have written here will sound overwhelming. You are tired, scared and confused (and you don’t need some arrogant geek telling you that you need to use technology to look over your doctor’s shoulder). Recognize that you will not have the capacity to bring your intellect to bear on this the way you could when you were healthy. It is very tempting to just check out and trust that the healthcare system is going to take good care of you. But please trust me on this: That’s a bad idea. The default settings on the healthcare system really suck. Your doctors will provide you with options, but they do not have the right perspective to help you make the right choices. Patients often ask their doctors, “What would you do if you were me?” The very, very best doctors reply, “But I am not you.” What you need to find are other people who share your values, who are living with the consequences of having made the choices that you are facing. I say this with both a deep sense of pride and a great deal of humility: My spiritual predecessors (health geeks) have made sure that the Internet can provide you with connections to these people.

The Internet will make it easier to connect, which is awesome. If you cannot summon the strength to do this, fine — entrust someone you love with the task of connecting for you. I truly believe that it is impossible to be an epatient alone. Moreover, I believe that it is impossible not to be an epatient if you have shared your burden with even one other patient.

For those who need encouragement with their ongoing efforts to connect to others with the same suffering, I leave you with some video happiness. Be sure to watch the whole thing:

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.

Related:

• Why geeks should care about meaningful use and ACOs
• Why developers should enter health IT contests