Fred Trotter

OpenEMR is now meaningful use certified.

Congratulations to the OpenEMR team!!

-FT

Keith Boone, well known and liked Health IT standards geek has written up a proposal that would make the next release of HL7 CDA based on HTML5 rather than XHTML.

I have just become more deeply familiar with this set of standards as the result of the extensive research I have done on my new book on meaningful use  of Health IT.

I can say, without a moment of hesitation, that this is a really good idea.

Everyone should support this proposal, b/c otherwise, CDA is a huge mess.

Which is not to say that an HTML5 version would not also be a huge mess. But I believe that it would be less of one.

-FT

This contest is deeply problematic.

The blue button initiative was a good initiative because it allowed greater access. It made that possible by ensuring that access to patient data did not have to wait for the VA/DOD/Whatever to create a download that conformed to the still-forming XML standards that make true interoperability possible.

But now the VA is promoting the Blue Button format as something that should be integrated into other EHR systems. That is unacceptable.

Meaningful use requries that doctors allow patients access to their health record summaries using CCR or CCD. Both of those standards can easily be translated to printable reports that are very readable. Meaningful use -also- requires that patients be provided a summary in a printed form. The simplest way to do this is just to have onsite printing of the CCR or CCD reports.

Blue Button data format is not as readable as a summary printout, and is not as parseable as XML. It is the worst compromise between human and computer readability. No clinician should ever make a clinical decision based on the content of a Blue Button download. The data is simply not rich enough to transfer into another health record or PHR. Essentially that makes the blue-button data format standard an FYI-only use case.

The innovation of Blue Button is to not let standards compliance get in the way of access. For this reason the DOD and the VA use of the Blue Button format should be applauded! The Blue Button initiative was fully give-me-my-damn-data compliant! But promoting it as an alternative process to a process that supports fundamental data reuse and is -already- required by meaningful use is unethical.

I formally request that the VA withdraw this contest, or make it clear that a CCR/CCD/printable report download meets the requirements of the contest.

Either you are promoting the notion of patient access, which is wonderful, or you are promoting shitty health data standards, which is unethical.

Cross posted on the VA challenge forums here.

Here is the example of the file format in question.

-FT

Google Health is no more.

Thats a shame, because I am writing a book on Health IT for O’Reilly and before this announcement, my rough draft featured Google Health extensively.

I guess this is better, though, than having Google Health shut down just -after- I finished writing my book.

Of course, I am going to have to change lots of content in the book, but Google Health will still be there.

For a project that no longer exists, it will end up being one of the most influential Health IT projects of our era. Google Health, and for that matter Google generally, has always been willing to make strong statements when they evaluate technology and technology protocols. In fact, Google has made two controversial technology picks and the opening and closing of Google Health.

At the opening Google decided that they would support CCR (Continuity of Care Record) from ASTM and AFFP rather than the much more complex CDA/CCD from HL7. The CCR vs CCD debate has been one of the most controversial and long-standing arguments in Health IT. HealthVault, the Microsoft product which survives Google Health has always elected to support both standards. But Google insisted that the CCD standard was too complex, and not only insisted on CCR, but a smaller subset of that standard.

Now, as the end support for Google Health, Google is choosing to allow export under the Direct Protocol. Again this is the simpler of the two protocols that is supported by ONC to be part of the NWHIN (the precursor to the Health Internet). The other protocol, IHE, is getting no love from Google Health.

Goodbye Google Health, whatever else I may have said about you, I must admit that you made some ballsy technical stands.

-FT

I am happy to mention that Medsphere has received certification for their OpenVistA EHR system.

As far as I know, this is the only meaningful use certification for Open Source software, for the in-patient setting. All of the other certifications that I have mentioned so far have been ambulatory.

Congratulations to the Medsphere team. This is an important accomplishment, and a milestone for the Open Source health software community.

-FT

I am happy to report (a little late) that ClearHealth is now the first commercial Open Source EHR product to be meaningful use certified.

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.

More importantly, ClearHealth is not ignoring the needs of its community users. They are developing a path to self-certification for ClearHealth users who rely on the community edition of the product. Pretty amazing stuff.

-FT

Recently, the AAFP and Surescripts announced Physicians Direct, a secure messaging service for providers.  But neither the article nor the signup page for Physicians Direct detail the most critical single issue regarding the service. This is a very large deployment of the Direct Project. This is by far the most important part of the story, but it is buried deep with the FAQs.

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.

-Trotter

To the novice, the term “interoperability” means that two systems can talk.

To the expert, it means that they can understand each other. To much of our current data interchange is “meaning poor”.

To get past that problem, we need to do lots of work with ontologies, which, loosely put, are knowledge dictionaries. Most clinicians in the US have no training in ontologies and their real-world experience is limited to billing ontologies like CPT and ICD. As a result, the value of proper coding is largely lost on the average clinician in the US. ( I wonder how this issue is understood by common clinicians outside the US…)

Those of us who obsess with the future of Health IT recognize that we need to find ways to make Ontologies more productive.

At this year’s health 2.0 conference, I caught up with Dr. John Mattison of Kaiser Permanente to discuss a tremendously important contribution that they are making to the Open Source Health IT community. I have already blogged about this significant ontology development from Kaiser. So I was really pleased to be able to get these kinds of details from the horses mouth. These details include that the license will be the Apache 2.0 license.

Part 1

Part 2

For whatever reason people simply do not get what the NHIN is and what its implications are.

This feels like a repeat of what happened to me more than a year ago.

The NHIN (which has been rebranded the “Nationwide Health Information Network” or NWHIN from “National Health Information Network” in response to these silly trademarks) is going to be the foundation of a new Health Internet. The US Government wisely will not call it that, because of the paranoid privacy histrionics that this would induce, but nonetheless it -is- a Health Internet. The definition of the word “Internet” is: Any set of computer networks that communicate using the Internet Protocol. The Internet, the largest global internet

The Health Internet by extension is the “largest Internet devoted to Healthcare Data”.

Here are the basic features of the Health Internet:

• You will be able to ‘email’ your doctor.
• Your doctor will be able to ‘email’ you.
• Faxing health records will go away.
• Eventually, your medical records will auto-magically follow you around the country, appearing when they are most needed in a moments notice.
• All of this will be done securely and in a way that fully supports peoples legitimate need for privacy.
• New innovative services will appear, that leverage the Health Internet data channel to create applications that were previously unthinkable.

How is this being accomplished? Simple as one two three:

1. The EHR stimulus money will be given out in response to “meaningful use” standards which include interoperability requirements, which will require connecting and sharing data, without specifying a specific technology stack. These standards will become more and more pronounced as time moves forward.
2. ONC is supporting the development of two Open Source projects that will serve as reference implementations of the two NHIN protocols: IHE and the newly formed Direct Protocol. Those projects are the IHE projects: (CONNECT Project if your are a federal agency and the Aurion Project if you are anyone else, updated 8-19-11) and the Direct Project (Direct). I recommend you watch this OSCON video for a basic explanation of these two projects.
3. The Federal Government will expose its considerable health data resources (i.e. DoD and the VA) using these two protocols. Agencies which accept the reporting of meaningful use measures will accept that reporting using one or both of these two protocols.

So are these protocols being mandated? No. But then neither were HTTP, STMP, SSH, SSL, or DNS. Its just what everyone uses. The VA has the single largest pile of detailed health records in the history of mankind. They will be available using either CONNECT-complatible IHE or Direct-compatible Direct protocol. They will probably not be available using your-favorite vendors idea of a proprietary health data exchange protocol.

This is going to happen. Hell, it already is happening. These reference implementations are entirely Open Source. They are designed to eventually handle the cases of communicating across national boundaries. This is going to the start of a international Health Internet. First with Canada and Mexico, and nations promoting Medical Tourism and then everyone else. It will take time. Adoption might be slow. But there will be a Health Internet, it will use these protocols. It is only a question of how long this will take to be adopted, and how long it will take people to stop talking in the abstract about the issues of Health Data Exchange.

This is happening. Adjust.

-FT

Hi,

I am a vocal participant on the NHIN Direct Security and Trust working group. Its a perfect place for me. I love Open Source healthcare, but my background was in InfoSec… and we never really forget our first love.. do we? At the NHIN Direct Security and Trust workgroup, I get to exercise all of my hats at once… and that is fun.

The purpose of NHIN Direct is to design an infrastructure for sending messages with clinical content between clinicians (and their patients). It is basically designed to be an email-like system for delivering health information. It is intend to eventually replace the current NHIN… which is the ad-hoc clinical fax network.

On a recent call, someone from the “Policy” department said something about our current plans to the effect of “I am not sure how putting the burden of Trust Decisions on individual providers will impact the ability of the project to replace the Fax network” I could not talk on the call… I was in a noisy airport… but I was surprised by that characterization of our work. In retrospect I can see how she would read what we are writing and come to the conclusion that we are putting new trust burdens on doctors… but in fact we want to lighten the trust burden they currently carry.

You don’t know the devil that you know

That is probably the most important point. The fax network comes with a very heavy trust burden. But we are used to it, so we rarely pay attention to it. This is a case of “acceptable losses”. Its kind of like Terrorism vs Auto Accidents. Many more people in the world are killed in car accidents each year than are killed by terrorism. The irony is that terrorism is much harder to fix than auto accidents. If the US Govt devoted the same budget to auto accidents that they do to the “War on Terror” we could probably prevent 99% of the auto accidents in the world. But we, as a society “accept” the burden of car crashes… because we are used to them. We have the same problem with medical errors… but that is another post.

So lets take a careful look at the “current trust burden” in the fax network. First, doctors do not actually deal with this problem directly. Typically they hire staff to do faxing. This isolates them from the problems that the “faxer” faces. It also means that they rarely hear of the errors.

“Faxers” fax to patients, and they fax to other clinicians. There are lots and lots of times when something that should have been faxed to Dr. Smith ends up going to Dr. Jones. We only hear about the most extreme cases. In fact before the existence of the NPI database, there was no reliable way to determine if a fax number was valid. If Dr. Adams wanted to send a record to Dr. Smith, his staff called their staff and wrote down the numbers. The numbers get jumbled, mislabelled and lots and lots of errors occur.

We do not hear of the cases where people were killed because information that was in a fax record was faxed to a wrong number. Perhaps sent to the “main hospital” fax line instead of the ER fax line where it was needed. These types of between-institution errors are almost impossible to detect, even the “big picture” at one large hospital is hard to sort out, and when you add another institution… no hope. Instead you get cases that are written off as “we did not know that X… oh well… nobody’s fault… nothing could be done”.

Then of course there is the assumption that fax lines are private. This is the farthest thing from the truth. Faxes, just like regular phone conversations are digitized and sent over the Internet. If a hacker gains control over a main router at a major Internet carrier, then they can re-route phone calls and faxes to themselves as well normal internet traffic. The fax network is actually going over the Internet right now… its just “obscured” rather than “encrypted”.

This is not the only problem with faxes, another problem is that institutions rarely have a firm grasp on how many fax machines are actually in operation. You can plug a computer modem into a wall and have a nearly undetectable new fax line… allowing “insiders” to send files to themselves via fax. In fact, phone lines can generally be re-purposed in to back-channel data ports in a number of ways, faxing is only one of them. Lots of my old Air Force buddies ended up at Securelogix, which is one of the top companies for phone security. They sell a telewall that can help prevent phone lines from being re-purposed. Its just what its name implies, a firewall for telephones. No large institution that I have every heard of that paid for a penetration test that include wardialing has ever had the wardialing effort return 0 rouge fax/modem instances. Clinicians should not assume that they understand their own fax infrastructure.

Even if you are really careful with who you fax to.. the current fax network is that it is difficult to maintain. Lets say that Dr. Smith sells his practice to Dr. Sneaky. If the fax number does not change, then Dr. Sneaky is going to get all of those faxes that were intended for Dr. Smith. Not good.

The problem with comparing the devil you know with the devil that you don’t know is that usually, you don’t actually know the first devil that well at all. The “trust burden” on the Fax network seems light because it is hopelessly broken  and we all just tolerate it.

A lighter burden

Which brings me to the “trust burden for NHIN Direct”. Our goal with regard to this burden is two fold:

• When an NHIN Direct user makes a trust decision, it should me more reliable than the equivalent decision on the fax network.
• Typical NHIN Direct users should be able to avoid directly managing trust at scale, making fewer and therefore better trust decisions.

The first one is easy. Without knowing exactly what standards we will be selecting at the time of the writing, I can already tell you that the security the NHIN Direct network will be an improvement over the Fax network. Moreover, it will provide more and better information to the users of the network than is possible with the fax network. Without going into the gory details, this is because PKI is better than post-it notes full of names and fax numbers for maintaining a secure information transfer.

The second one is a little tricky. What I mean by “trust at scale” is the problem managing lots of peer-to-peer trust relationships. If we have a NHIN where say, a third of all doctors in the Unites States participate, that is still probably over a million people. There is no way that you are going to get a doctor to make a list of all of the doctors that he/she does/does not trust taken from a million person list. Even trying to do peer-to-peer trust on a city level would not work. Hell I would be surprised if it would work even between two hospitals. (If you gave doctors the option to “not trust” some doctors at their own hospital… you would probably still get headaches). The fax trust management problem is a little simpler because you can sometimes aggregate to the organization… several clinicians share the same fax, but even that it is really difficult. Having to manage thousands of trust relationships dramatically increases the probability that you will get one of them wrong.

How do we fix that? We need trust aggregation points. So far there are two of these in our model. The first is at the organization level, just like faxes. Typical NHIN direct addresses for providers working in hospitals or clinics will look something like drsmith@nhin.localhospital.com the “nhin.localhospital.com” part of the address is the “health domain name” and you could use that to trust all of the messages that came from that health domain name. The second way is with what we are calling Anchor CAs. For those familiar with the way CAs (Certificate Authorities) work with https, it is basically the same. The difference is that there will be no “automatically included” Certificate Authorities. When you login at amazon your browser makes a secure connection automatically because the person who makes your browser decide for you that you would trust Versign CA certificates. You can find out how your browser developer makes this trust decision for you… but they are still making the decision for you.

That model… where someone else makes your trust decisions for you… is not going to fly in healthcare. The stakes are simply to high to outsource trust in this fashion.

However, the notion of aggregating trust using Certificate Authorities is a good one. Lets imagine that my home town, Houston, decided to setup a Certificate Authority. They would decide on some reasonable policies for things like:

1. Anti-virus (think Storm Worm not Influenza)
2. Firewalls
3. at-rest disk Encryption
4. Password Strength
5. Local Authentication (two factor?)
6. Logging
7. etc
8. etc

Then the Houston HIE would create a CA, and that CA would “vouch” for organizations and individuals on the NHIN Direct network. BobsClinic might signup for the CA, then the CA would follow a bunch of steps to verify that BobsClinic was legit and was willing and capable of following the policy… and then the CA would say.. ok we are willing to vouch for BobsClinic.

Most clinics in Houston who wanted to use NHIN Direct could “import” the public key of the local CA. That’s fancy talk for they would accept the vouches that the CA made for all of the organizations that signed up. Those of you with security backgrounds understand that we are talking about a pretty basic CA infrastructure, but we wanted a way to make the trust decisions that clinicians would be making under this model free of unneeded technical language. So we are calling the CA, and all of the people that the CA “vouches” for a “Trust Circle”. It makes sense… if you have not imported the certificate of the CA, you are “outside the circle”, if you have imported the public cert of the CA then you are “inside the circle”.

This “Trust Circle” notion will reduce the number of trust decisions that typical NHIN Direct users will need to make. Of course, it will be really important that clinicians are very careful when they evaluate the policies and enforcement provided by a given CA. Those policies should meet or exceed their internal standards for handling PHI. It is important because you are not just trusting one organization… you are trusting lots of organizations “through” one organization, a much bigger deal.

Trust Circles get around the thorny problem of managing peer to peer relationships, but the also dodge another bullet. They avoid the need for a top-down single CA architecture. Things would be much simpler, technically, if the NHIN (which is a too-vague term BTW) would just setup the one-ring-to-rule them CA and make everyone in the United States follow the same policy for exchanging health information. That is a deal killer for about a hundred reasons, here are a few…

• You are going to try and force catholic charity hospitals to share information with planned parenthood clinics.. are you kidding?
• Making psychiatric hospitals message each other in the same way that normal hospitals do?
• Make children’s hospitals message the same way that normal hospitals do? (kids are not just short people… Think about it.. Does the step dad get NHIN Direct messages for little johnny or only his biological father get them? Tough issues there.)
• Create a policy that is guaranteed to be legal in all 50 states? (think about the implications of medical marijuana in California alone)

Policy is really really hard, even if you do not assume that you are going to get everyone to agree. Assuming that everyone will agree… makes the NHIN a non-starter.

Trust Circles (plural) gets you out of that problem. When organizations and clinicians can see eye to eye on policy, then they can use NHIN Direct to communicate secure messages… when they can’t see eye to eye… nothing in the NHIN Direct security protocols will attempt to force or even encourage them to compromise.

Another thing to note is that there is nothing in the design that prevents NHIN Direct users from managing trust relationships one at a time. You do not have to join Trust Circles to send messages with NHIN Direct. If you want to “self-sign” your certs and exchange them on floppy disks, in person, with people you trust.. that works too! That is why I used the word “typical” above…

But now we come to the real problem.

The first step is..

Even though the trust burden of the NHIN Direct system will be less than the trust burden of the current fax network… it may not feel that way. The reason is that we have not actually taken responsibility for the trust we place in the fax network. We continue to pretend that everything is fine. But its not. The fax network is irreparably broken and the first step towards fixing it is NOT to try and design a new model without a heavy trust burden, but to recognize that we have problem. Once we do that we can see that indeed “the burden is light”.