RPMS, the VistA cousin run by the Indian Health Services has received ambulatory and inpatient meaningful use certification.
RPMS is substantially available under FOIA, (there are some proprietary components required to emulate the certified stack, I believe) and is the first Open Source stack that I know of to be certified as both inpatient and ambulatory.
Consumer reports is invaluable tool for the purchase of almost anything.
Anytime I am considering a major purchase like a car, or perhaps expensive electronics, I always by temporary access to consumerreports.org. While the Consumer Reports magazine can be interesting to browse, the website is even more valuable. You can access any recent product review done for the magazine in an instant.
Consider going to the car lot to buy a car and then comparing two similar car models. Both of the new cars cost about the same amount of money. Both of the cars have the same essential features. Which brand of car should I buy?
The problem here is that there is an asymmetry of information. The car sales man knows much more about the performance of these brands of cars than I do. So there is a danger that he will recommend the worse of the two cars, which he will have over-priced. If I trust the car salesman, I might be doing what is best for him, not best for me. Even if the salesman is honest, he might be making his recommendation based on what the needs of the average car buyer. To the degree that I am different from the average car buyer, my needs might be different.
Consumer reports helps to reduce this asymmetry. I can learn about how the cars perform from an objective source. I might end up taking the car salesman’s recommendation… I might not. My decision will be based on -my priorities- which can be very divergent from both a typical customers and from the salesman’s interests.
This kind of information asymmetry is even more pronounced in healthcare. I could learn what a car salesman knows about cars in about a month of diligent study. But to understand what a doctor does I would have to study for years. If I am trying to make a decision like “Should I have this surgery” I am at the mercy of the doctors much-greater information position. The Surgeon might be recommending surgery because that would generate income. He also might be recommending surgery because he is assuming that my priorities are the same as the “typical patient”.
Rectifying this information deficient for as a patient is much more difficult, because the resources available to patients are often problematic.
The information on WebMD is probably accurate as far as it goes, but it is dumbed-down. You can always spot information that might not go deep enough on the web, because it always ends with “ask your doctor about…”. That is the least helpful thing to say here. It means “This is actually a much more complicated issue, but we are not going to give you any more information, instead go ask the car salesman (the doctor)!”. It is the doctor that I am trying to evaluate here!
Wikipedia has much more accurate information that goes much deeper, but its articles are of sporadic quality (usually very high, sometimes very low… which one are you reading now?) and it may not be updated with the latest information on its more esoteric articles. It was not never intended to be relied upon for medical information that changes very very rapidly.
My boss and collaborator at the Cautious Patient Foundation Dr. Cari Oliver has just written a detailed blog post where she details how patients can use at service called uptodate.com to get around this problem. This service is intended for doctors, but they have recently allowed temporary access rates so that patients can access a topic or two and not pay the expensive yearly access fee. Of course, this service is aimed at doctors. It might be a little over your head. But it is better to have access to accurate, recent information about the risks and benefits of different procedures, from a disinterested third party authority that is too complex than not to have it all!
This type of recommendation excites me as a technologist passionate about social change! This is a classic example of using information to make patients more powerful!!
I hope to get more information about exactly what the partial certification means and what the meaningful use strategies of these organizations mean, but this means that the ClearHealth is no longer alone in certification. (Although from what I can tell, ClearHealth remains the only fully certified Open Source EHR)
I think the notion of simple graphical URLs is beautiful and elegant. If my wife were a graphical data object, I think she would be a 2D QR code.
Think of it, you can put links anywhere you want, in the real world!
You can put them on tshirts, coffee mugs, stickers, business cards… anything in the real world becomes a link to something in the virtual world. Awesome.
I have been playing with QR codes, with an eye towards gamification and behavior change for quite some time. I love the fact that with android and/or iphones you can rely on the GPS coordinates that webkit (the core of both browsers) will provide, makes a QR code a token that can do different things in different places. Think of the possibilities!
You could make geo-caching much much more interesting…
But how do you make durable (or intentionally not durable) QR code in a reproducible way? How do you manufacture large QR codes, that can be scanned accurately at a distance?
The first approach is simple to print the QR codes on either single sheets (A4 or US letter) and then clear paste them to some type of flat surface. You can use throw-away planks of wood from the hardware store to make durable QR code links. But what if you want to make a QR code on some permanent surface, like a wall or pavement. This basic idea can be taken pretty far, for instance you can paste the printed QR codes into ceramic tile or even bake it on, for a near permanent tag.
The simplest solution would be to use a stencil with black spray paint. QR code scanners vary greatly in their ability to pick up contrast, but the color black, and some other color, will almost always pick up. This has an advantage over gluing paper, because you can tag objects that are not entirely smooth. Moreover, with spray paint that does not damage the surface (more later) you can create images that can be placed out in public, non-destructively.
But what is the problem with a QR code stencil? In a word, islands. In order to make a stencil with, say, photo paper (which would otherwise be a great technique), you need a way to address bits that the stencil needs to block, that are not physically connected to the rest of the stencil. Its easier to show than explain. If you are spray painting black, for instance, and you want to make a stencil of the following QR code, you will have the following trouble spots:
See the issue, the two anything white, that does not connect to something else white (even by a corner) is going to be an issue. You might be able to make something clever for the places where this happens in most/all QR codes, but each QR code is going to have random “islands” that are often just one pixel big… and in different spots each time. These are the real headache. Making a traditional stencil simply will not work.
Also, making a stencil is very very slow. If you have to cut each pattern by hand.. ouch… way to much time. We need something faster too!
My first approach to solving this problem was to try and find a programmatic solution. For a given URL, there are many different ways to encode into a QR code. It might be possible to use an algorithm that detects this type of “island status” to find a QR code solution that did not happen to have any islands. You could make an application smarter by posting meaningless GET variables at the end of a URL until you found a version of the URL that would work (of course, I am focused on using URL shorteners like bit.ly to ensure that you have a simple-as-possible QR-code. The more character in the URL, and the more complex the QR code is and the harder it is to make a stencil. The shortener ensures that the QR code is manageable.
I gave up on this technique after noting that there were islands in all of my test runs for various URLs, but the idea is sound.
I have been meaning to write about this for a while.
Glen Tullman and I have pretty different opinions about Health IT. Glen is the CEO of Allscripts, which is the largest proprietary EHR vendor in the country. When ONC called for testimony for the definition of meaningful use, Glen and I sat on the same panel. I testified after him, and I painted a much different picture of the state of Health IT than he did. The summary of his testimony: “The future of EHRs is already here, we are doing meaningful use today”. The summary of my testimony: “There is a market failure in Health IT, no other industry needed to be paid to computerize”. He holds his own software company out as an example of the “right way” where as I generally hold VA VistA, which was developed in a Open Source collaborative fashion as the way forward.
Of course we are both financially biased in this regard. I am an upper-middle income software developer, and Glen got paid $4,072,270 last year. Given the kind of money I make on this Open Source stuff you should probably take everything I say with a grain of salt, and take everything he says with about 45 grains of salt… you know… based on the relative bias involved…
But Glen Tullman got an opportunity to testify again (without me this time), regarding VA VistA. (text, video)
In this testimony, I want to focus on one specific statement, that is particularly galling to me.
While the private sector has been moving forward in light of these incentives, the Government has been investing in their own proprietary systems for many years. Billions of dollars have been spent to build and implement the VistA/CPRS system within the Veteran Health Administration and the AHLTA system within the Military Health System.
So the VistA/CPRS is “proprietary”, while Glens own software is “private sector”. Wow. The Chewbacca defense at its best.
VistA/CPRS can be run for any purpose, the sourcecode is available for anyone to download without cost, you can redistribute those copies of VistA/CPRS without cost, and you can also redistribute modified versions of the software. That means VistA/CPRS meets the definition of freedom-respecting software, which is the soul of Open Source. Moreover, it was and is developed in a collaborative fashion that is at the heart of every successful Open Source project. If you want to know more, you should read What is VistA Really page that I edit for WorldVistA.
Then, Glen takes credit for accomplishments of Open Source technology:
For example, in Hartford, Connecticut, we have been partners in a project for almost two years that has not only led to widespread health IT adoption but successful implementation of open source health information exchange technologies.
What Glen meant by this is that there are some Allscripts node on an Open Source HIE created by MOSS, Misys Open Source Solutions. In short, Open Source -was- responsible for the exchange, and this had very very little to do with Allscripts software.
He goes on to say:
the fact remains that VistA’s basic platform, which relies on the 25-year old technology called Mumps, cannot support the open, flexible approach needed by those providing care to our nation’s wounded servicemen and women. Rather, the demands of today’s military and veteran healthcare environment necessitate the use of technologies – such as those based on Microsoft’s architecture – that can support an open, shared approach that will not just be desirable, but a fundamental requirement in the near future.
It should be noted that -every- instance of VA VistA inside the VA is capable of communicating with every other instance of VistA inside the VA. The VA was the first and probably still the only large scale organization to achieve this kind of internal data fluidity, which has been happening for more than a decade. Interestingly, the other “large” vendor in Health IT is Epic, a proprietary EHR company that relies heavily on MUMPS. I can think of nothing that Allscripts software can do that either Epic, or VistA is not capable of. Holding out Microsoft technology as a source for peer-to-peer leadership is also pretty ironic, but whatever…
Glen is pretty used to speaking out of both sides of his mouth regarding Open Source. And this testimony is far from the only instance. First there was this article in Forbes, which originally claimed that Allscripts had an Open Source platform, but was then quickly redacted to its current “clearer” status. This was not before it was completely flamed..
most recently, Glen was interviewed in the January 2011 Edition (Vol. 19, No. 1) of HealthData Management Magazine
And Tullman has spent those years (since 1997) being a relentless advocate of the use of open source architecture for health I.T. software and pushed his company to develop tool sets to connect its EHR software with virtually any device or software on the market.
This is was, of course, published in time with the edition of the magazine that would be available during the 2011 HIMSS conference.
This is a very disturbing case of a proprietary EHR CEO being completely intellectually dishonest regarding Open Source. I am on speaking terms with several of the top CEOs of proprietary EHR systems. People like Jonathan Bush of Athenahealth and David Winn (formerly CEO of) eMDs. I have advocated Open Source to these figures on a regular basis. But the remain proprietary companies because they believe that they will make more money as proprietary companies. I believe that Open Source has value that should be more important than profit, and have a friendly disagreement about this with most industry CEO’s. They think my ideas are intriguing and have potential, but see no reason to “bet the farm” on Open Source.
But they also -never- hold themselves out as the “Open” or “Open Source” option. Nor do they malign technologies merely because they are other than those chosen by their own developers. Glen Tullman regularly does both of these. Hell, he did in testimony to Congress.
Look I know that not everyone agrees that Open Source is the way to go, this is not what I am arguing here. I am arguing that we need to have honest and sincere disagreements about licensing and technology issues in Health IT rather than listening to Glen Tullman and his Chewbacca defense.
This project holds a special place in my heart, since David Uhlman and I started it years ago as next generation PHP-based Open Source EHR. It is theoretically possible that some code that I wrote, all that time ago, has actually carried over into this certified version. A careful analysis of the sourcecode tools would probably reveal that I can take credit for perhaps 5 or even 6 carriage returns, in the current ClearHealth code-base.
In all seriousness, the ClearHealth project has grown by leaps and bounds. The PHP-product from ClearHealth, Inc has leveraged many of the innovations from the WebVistA project. Making it probably one of the most capable and robust web-based EHR systems in existence. Only OpenMRS competes in terms of complexity and scope at this stage. Unless Tolven, OpenEMR, PatientOS etc can get their act together, this certification will set ClearHealth aside as the “one project to rule them” in this space.
That means that the service is compatible with other large adopters of the Direct Protocol. Most notably, HealthVault has just launched a beta deployment of Direct.
Think of the implications of this. One of the largest PHR providers in the country is on the network, one of the largest network of doctors is on this network.
We are watching the birth of the Health Internet.. its is truly wonderful to be involved in this work.
When I tell my grandkids what I did with my life, I hope the links to my early posts on the Security and Trust Working Group of the Direct Project are still up. “I was part of that from the beginning” I will say… My previous plan was to tell them that I invented bubble-gum ice cream, and then enjoy basking in their amazed adoration, until they discovered that Grampa’s stories are “unreliable”.
This will work out much better.
This is also a tremendous step for Surescripts away from being a proprietary network provider. For those who are unfamiliar with Health IT, Surescripts has a monopoly in e-prescribing after buying out its only competitor several years ago. If you e-prescribe in the United States, there is a 99% chance that the data cross the Surescripts network. Surescripts is free to use for Doctors, but the pharmacies pay for the privilege. But that business model will die as the Health Internet grows. Once the pharmacies realize that you can use the Health Internet to exchange prescriptions rather than the expensive Surescripts network, that business will dry up quickly. Moving into the Health Internet provider business is the only chance Surescripts has at long term survival. This is a very smart move for them.
Of course, this also has implications for meaningful use. Providers can use this exchange network, without making an expensive investment in EHR technology, and still qualify for part of the meaningful use dollars. $15 a month might seem expensive for glorified email, buts a whole lot cheaper than an EHR.
Commitment contracts are a way of limiting and shaping your own behavior.
If you know that your “future self” (a useful Behavioral Economics concept) is going to be weak willed, you can make a commitment that limits your future behavior to do the “right” thing.
The classic example that everyone always uses of this is of Odysseus and the Sirens. Odysseus has himself tied to the mast of the ship by his men, so that he will not be able succumb to the siren’s song.
I think commitment contracts are probably the single most important tool we have in hacking our own motivations. Currently you can make commitment contracts through stickk.com, but I have been thinking carefully about how to make commitment contracts into something that you can access in code.
I think this is going to be a central theme moving forward with the Programmable Self concept, so you can look forward to many more posts about it.
So I have decided to start blogging about “programmable self”. For that reason, I will be re-publishing the programmable self category from fredtrotter.com on programmableself.com.
Programmable self is a merger of two sets of concepts, quantified-self which is the use of technology to get accurate data about yourself, and behavioral economics/psychology which deals with motivation and behavior.
The concept is pretty simple. The same way that quantters (people who track themselves, using quantified self methods) use software to track data about themselves, you can also automate certain aspects of motivation.
This is really important, because for the most difficult life change issues, the problem is not knowledge, but motivation. Using quantified self, a motivated person can perform better. But the problem is how to become a motivated person? The really difficult things to change about ourselves come with tremendous intrinsic motivators. Overeating, anything to do with sex, alcoholism, drug addiction, gambling or any combination of the above have tangible, pleasurable outcomes. Orgasms are pretty amazing experiences, and if we want to change behaviors like condom use, we need to delve deeply into changing motivations.
Before I get started blogging, I should probably acknowledge that many of the concepts that I will be discussing are either inspired by, borrowed from or criticisms of the work of several behavioral economists.
Moreover, I am not the first person to attempt to harness these ideas in software.
To start with, most of what I say here will only be consumable by quantters, programmers and hackers like myself. Eventually some of the concepts that I am dealing with here should become available to “regular” users!
I have recently been approached by several policy people who are interested in ensuring that the consumer/patient is at the center of the coming Health Internet.
Through my work at the Cautious Patient Foundation, I have become pretty obsessed about only working on patient-centered and patient-empowering technologies. I often work on software for doctors, but only when it happens to also empower patients.
For that reason, I have chosen to donate time to the Direct Project. I was one of the more active members of the Security and Trust working group, and what I am about to describe relies heavily on the trust model that I advocated for (along with Sean Nolan, from Microsoft… strange bedfellows… I know…).
I believe that any consumer advocate should be helping to ensure that state and regional HIE efforts, as well as the RECs are fully informed about the basic implications of the Direct Project. They need to understand what their role is… or more precisely what their role is not.
I argue that the Direct exchange model is fundamentally empowering in a way that the IHE model is not… yet. To understand why you have to look carefully at the basic routing models of the two systems. Lets imagine that I change doctors from current doctor, in Houston, to a new doctor in Arizona. If I were to transfer my files using the IHE NW-HIN this is how it would look:
Each little blue hexagon is an organization that believes that it is determining the trust, privacy and interoperability policies for its constituent members.
See the problem? In order for there to be a path between health provider A and health provider B a pretty large number of trust relationships will need to be in place, and everyone has to agree. In the short term, that is a pipe-dream. IHE requires complex routing with lots of very specific decisions at each “blue” point. The organizations that are in charge of making these decisions currently have no idea how to implement their policies in either IHE or Direct protocols. For the most part, the deciders just dribble on about trust relationships and policy decisions without any clear understanding of the technologies that will implement those features. Further, the IHE technology is a complex protocol, and sometimes complex routing decisions will not be possible in initial generations of the technology and/or protocol.
There are good reasons for this architecture. It can work, entirely in the background, without the patient (you) having to initiate are request. This is pretty good if you are showing up unconscious in the new city… Your records will just magically appear in the ER from the network. But what happens when Planned Parenthood has records for your and a Catholic Charity Clinic is making a data request to the network for you? Those kinds of tremendously complex issues are all handled -inside- the IHE protocol and its open source implementation the CONNECT project.
Now lets consider how this health record process would occur on the Direct Exchange:
Ok its worth taking some time to explain this. The Direct project is specifically designed to handle point-to-point trust relationships for Health Information exchange. From the Direct Project Security Overview (I actually wrote this part):
In the same way that clinicians currently do not assume that it is safe to fax protected health information to anyone with a fax number, or mail PHI to anyone with a post office address, Direct Project users should not assume that it is safe to send messages to any Direct Project address. Direct Project users will need to establish real-world trust relationships with other Direct Project users on their own terms, but once they have established this real-world trust, they can be sure that a Direct Project network will securely deliver Direct Project messages to the trusted Direct Project user.
So the “old doctor” needs to configure his EHR to trust my PHR. I need to configure my PHR to trust his EHR. Once that trust has been established, I can securely receive a copy of my records knowing that there are no untrusted intermediaries. The “privacy and security” policies need to be agreed upon only by me and my doctor.
Similarly the “new doctor” and I need to establish a trust relationship. Once this happens I can forward a copy of my records.
So what does this have to do with patient empowerment and consumer-focus? In my mind, everything.
No one but me and my doctor need to agree regarding privacy and trust. Once the doctor is sure I am really “Fred Trotter” he can transfer anything he wants directly to me.
The old doctor and the new doctor do not need to trust each other. The both need to trust me.
I do not need any third-party permission to send data to and from my doctor. If I want to setup my withings scale to pump my daily weight measurements into my doctors EHR… I can do that.
My PHR is a peer on the Direct Exchange network. The model is PHR-centric and is therefore patient-centric.
In the Direct Model, the patient can literally the center of the transfer. If the “old doctor” and the “new doctor” have a trust relationship, they can directly exchange information about me. But they do not -need- to have a trust relationship for the network to function.
Eventually, the IHE-based Health Internet will support patients as equals on the Health Internet. Eventually, the routing between different IHE nodes will be more direct, and then the benefits of IHE might begin to outweigh the benefits of the simple Direct Exchange.But for now, the Direct model empowers the patient in ways the IHE model could never hope to.
So what does that mean for policy makers? For whatever reason, every time I study a local, regional or state HIE effort, they all seem to be pushing the top-down HIE model. There are many things that a local HIE exchange could do to facilitate a Direct Exchange model, but for whatever reason, I do not see Direct being discussed by the RECs or by the local exchanges. I can understand why. In the Direct model, the task of a local exchange is to facilitate trust relationships and then get out of the way. The local exchange never gets to have a local copy of the patient data or even to see the patient record go by on its way somewhere else. They are much much less important under the Direct exchange model, and in fact, a Direct Exchange can happen without the cooperation or facilitation of any “HIE organization” or REC. This is much much closer to the distributed peer-to-peer nature of the Internet, and those involved with the Direct Project believe that in the end, it will be substantively easier for organizations to use than a IHE-based local HIE.
The Direct project is backed heavily by Microsoft Healthvault and members of the Google Health team are now participating as well. Those are the two dominant commercial PHR systems available. I believe both of them are just waiting for something like the Direct Protocol to blossom into really useful tools. Both of these tools have solid consumer-facing options available today.
At every level, organizations are deciding whether to invest in Direct or IHE-based exchange. At this point, I believe the only viable option is for a local exchange to either support Direct only, or both Direct and IHE. IHE is simply going to be too heavy weight for early adoption. Eventually, IHE may become dominate but for now Direct is much simpler, and puts the patient right in the center of everything. If you are a policy maker, you should be asking anyone involved with an HIE process to detail what their Direct-strategy is. If any effort is ignoring Direct and going with IHE-only I would lay odds that they will be broke and defunct before the decade is out.
Moreover, an IHE-only strategy is going to exclude direct participation from patients at this stage. If you care about patient empowerment, I recommend that you advocate for the Direct project at every level, including in your local HIE and REC.
(Update 2-16-2011) Keith Boone, a collaborator of mine on the Direct Security and Trust working group, and one of the architects of IHE points out in the comments below that there is nothing in the IHE protocol itself that dictates that it should be used in this fashion. He is partly correct about that. The protocol itself indeed has nothing inside of it that dictates this design over another. However, the inherent complexity of the protocol does means that when IHE happens, it will happen in a “centralized” manner. There is no other way for any given community to accomplish IHE, other than to pool resources. That pooling of resources ends up meaning that the IHE chart I drew is inevitable initially, but as IHE competence spreads it might become more peer to peer. In any case it hardly matters ‘why’ the tree structure I diagrammed is happening… it -is- happening. Every HIE I am aware of, other than Direct-based efforts, are presuming this tree model. It is certainly what is happening in Texas.