Novice EHR Development is now unethical

The original Hipoocratic Oath states:

I will not use the knife, not even on sufferers from stone, but will withdraw in favor of such men as are engaged in this work.

One modern version reads:

I will not be ashamed to say “I know not,” nor will I fail to call in my colleagues when the skills of another are needed for a patient’s recovery.

The idea here is that a doctor needs to recognize when another practitioner has a skill that they do not, and that they must refrain from “practice” when another person has demonstrable expertise in that area of practice.

It is now 2013. It is time for doctors to stop “writing their own EHR” from scratch. They need to bow out of this in favor of people who have developed expertise in the area.

I just found out about another doctor who has decided to write his own EHR, because he has not been able to find one that supports his new direct pay business model adequately. In the distant past I encountered a doctor who believed that his “Microsoft Word Templates” qualified as an EHR system. This is a letter to any doctor who feels like they are comfortable starting from-scratch software development for an EHR in 2013 or later.

You might believe yourself to be an EHR expert.

Are you sure about that? Are you sure that you are not just an EHR expert user?

This difference is not unlike your relationship with your favorite thoracic surgeon. Or for that matter, your relationship with the person who built your car. The fact that you are capable of expertly evaluating and using EHR products does not mean you are qualified to build one. Just like the fact that you are qualified to treat a patient who has recently had heart surgery or to discern when a patient might need heart surgery does not make you qualified to perform that heart surgery. Similarly, the fact that you can drive, or even repair your automobile, does not provide you with the expertise you need to build a car from scratch.

The ethical situation that you are putting yourself in by developing your own EHR is fairly tenuous. Performing heart surgery without being a heart surgeon, building and driving your own car without being an automotive engineer and a doctor coding their own EHR system from scratch all have the same fundamental problem: You might be smart enough to pull it off, but if you don’t you can really mess up another person’s life. Make no mistake, you can kill someone with a shoddy EHR just as easily as by performing medical procedures that you are not qualified for or by driving a car that is not road-safe.

It is not that heart surgeons, automotive engineers and EHR developers are not going to kill people with faulty performance. All experts are fallible. But they will kill far fewer people than you would, performing outside your expertise.

I can understand your feelings of frustration. You likely have totally different goals in mind than the average third-party-payer oriented EHR system has. You are right to be frustrated with the shackles that those systems have placed on you. But you are very wrong to presume that it is ethical for you to do “amateur hour” on your own.

You presume that because you can see the problems with EHR developer performance, that this makes you qualified to build a better EHR. You are utterly and unequivocally wrong about this. Sometimes, EHRs have features that are designed for clinical CYA, basically over-documentation for the sake of unethical defensive medicine. Sometimes EHR systems are designed to be glorified practice management systems, designed mostly to ensure that doctors maximize their paycheck at the expense of patient care. Sometimes EHR design decisions have no rational behind them at all… they are frequently the result of original design whims that are hard to correct in subsequent editions of an EHR product.

But sometimes a feature that frustrates you is precisely what makes that EHR safe for patients. I can promise you that you cannot tell the difference between flaws and features without looking carefully at both the internals of the EHR system and all of the clinical workflows it is exercised in. What you think of as a flaw might be a software crumple zone.

Happily, you get to have your cake and eat it too. There are several Open Source EHR systems that are already meaningful use certified. You can use these Open Source EHR systems for nothing, and for very little money you can even get Meaningful Use credit for using these systems. Given this, you have no excuse to continue to develop an new EHR.

Open Source gives you the right to change what you need to, in order to get the functionality that you want.. and more importantly can connect you with experienced health IT developers, who can serve as a gut check for you as you consider how to implement the features that you need for whatever clinical variation you are interested in implementing.

This is very like the person who orders a “kit car” to build in their garage. They get to -feel- like they are building the car, and indeed they get lots of options normal car owners do not. But in the end, they are able to build a car safely because someone else, someone with specific expertise, has made sure that design of the kit car is fundamentally sound.  You can always shoot yourself in the foot with kit cars and Open Source.. but you have the power you need without being in over your head.

The development of mature EHR systems has been very similar to the development of surgical methods. Primitive EHR systems and primitive surgical procedures were both deadly. In both cases, medical science has already sacrificed thousands of people to the “cause” of learning how to do these things right. In 1850, it would have been entirely appropriate for any doctor to “dabble” with creating their own surgical methods. Even as recently as 2000, it would have been appropriate for you to “dabble” with the creation of your own EHR system. (eMDs was started by a doctor dabbling in 1996. eClinicalWorks was started in a similar fashion in 1999). But those days are over.

A doctor developing a new EHR system from scratch, by themselves, without extensive Health IT programming experience is in over their head. If they continue to develop an EHR, even after being warned of the dangers here, then this is hubris.

Ask yourself: Are you absolutely sure that this action is not a fundamental violation of the oath that you took when you became a doctor?

I want to be clear, I have worked on or around the development of EHR systems for more than a decade, and I would not presume to write a new EHR system without a team of programmers and years of funding. Its not that I think that “a doctor” is not qualified to undertake this task. No single person is.

I wrote a book designed to ensure that novice programmers had basic training in complex Health IT principles. Programmers can be guilty of hubris too, and I consistently advocate for a “clinical pair programming” approach. David Uhlman (my co-author) and I wrote the book because too many people assume that Health IT is easy, and they wonder why things in the industry are so “primitive”. The book is intended to teach clinicians and programmers alike humility when approaching clinical information systems, both as users and as developers. FSM knows that I have been dangerously arrogant regarding clinical information systems, and I have and will make serious mistakes. But there comes a point where making the same mistakes that others have made, and written about, becomes unethical. I think we have reached this point with EHR systems.

Some people took offense that I should link to my own book at the end of this article, so instead I have included some of the reference materials that I use frequently. This is a good sampling of the kind of context that really should be required of any modern Health IT developer.

Begin with Information and Medicine by Marsden S Blois. Then move on to Principles of Health Interoperability HL7 and SNOMED by Tim Benson and The CDA Book by Keith Boone. Finally, you should read about what can go wrong in Health IT by studying EHR generated errors with Clinical Information Systems, Overcoming Adverse Consequences by Dean E Sittig and Joan S. Ash.

These are the books that I refer to when I get stuck on something. I wish I could just hold it all in my head, and in many ways my book is just the cliff notes I need for myself. If you know of other books that should be on the “Health IT required reading list” please leave them in the comments…

-FT

Using HTML5 as the basis for HL7 CDA v3

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

Unethical Blue Button Contest

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: influential, controversial and gone.

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

Medsphere OpenVistA meaningful use certified

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

ClearHealth, the first Open Source EHR Meaningful Use certified

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

Direct gathers steam

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

Kaiser Ontology Interview

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

Health Internet

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