You can always read all of my posts there by visiting my strata author page.
Alan Viars is making the case for simpler direct directories.
He has allowed me to republish some of his ideas here!!
A couple of weeks ago, I attended ONC’s Direct Bootcamp in Crystal City, VA. A hot topic at the two-day conference was the notion of a “Provider Directory” that incorporates Direct email addresses.
I also read that HHS/CMS intends to revamp the National Plan and Provider Enumeration System (NPPES). This is the system that manages National Provider Identifiers or (NPIs). Every individual provider and provider organization has one of these numbers, sort of like a tax ID for providers. A common complaint I hear is that it contains information that is often out of date and/or incorrect.
So what, you might ask, does the NPPES have to do with the Direct Project? Having worked with the NPPES data and having some background with Direct, the idea of “killing two birds with one stone” has captured my imagination. (Nerdy and wonky I know.) This is an opportunity for government efficiency by consolidating systems. Efficiency can only be achieved if the new system is simple, however. Too often in health information technology, consultants and vendors introduce complexity for complexity’s sake. After all, complexity is good for the bottom line for many companies because it means more billable hours and more services sold. Sadly, I see this sort of thing all the time. As an American and a taxpayer it ticks me off.(See footnote)
To illustrate what I mean by “simple”, I’ve built a prototype web service application that illustrates my vision of a combined NPPES and Direct email Provider Directory. Before I outline that technical proposal, however, I’d like to point out how adding some other data fields to NPPES could result in a an empowering service for patients, providers, and payers.
The whole article is worth a read. The man makes a good case.
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…
For those wondering, the Direct Project is a secure email protocol based on SMTP/S-MIME for doctor-doctor and doctor-patient secure communication. It is all-but-required in Meaningful Use version 2 and it is intended to replace the fax machine for the transfer of health information in the United States. I had a hand in designing the protocol.
NPPES is the authoritative source of doctor contact information in this country. <shamelessplug> DocNPI.com is probably the best way to actually search the NPPES data, and we have an API and everything. </shamelessplug> But you can download the NPPES data yourself and almost every insurance company, clearinghouse, HIE vendor, etc etc does this on a regular basis, in order to ensure that they have updated contact information for doctors, hospitals and other organizations in the healthcare system.
The NPPES publishes the NPI, which is basically the “social security number” for doctors and hospitals as they conduct business. Anyone who is legitimately connected to healthcare can get an NPI and you should, just so you understand what the signup process looks like.
When you register for your NPI, you have the opportunity to insert your contact information. Once you have an NPI, CMS publishes that contact information. This is the list of every possible contact field in the NPI data:
This bundle of information is what a physcians is required, under HIPAA (the parts no one pays attention to) to keep updated. Right there in the middle you can see two fax numbers. As long as the NPPES data does not have a Direct Mailing address listed in addition to Fax numbers, the message from CMS is clear “Use Fax for health information exchange, not Direct”.
Here, are the reasons that NPPES is really the only place that a centralized Direct provider directory can be kept.
Mostly, I just wanted to write this down as a brain dump so that others can easily email a link around as to why this is not a terrible idea.
I have proposed this several times, in person and I believe in some comment to Meaningful Use or something else on regulations.gov. I am certain that I am not the only one, but I tend to be more vocal than average about Health IT policy implementation details. But I cannot find what I have already written anywhere, and it is probably included in something longer I wrote. I am unfortunately given to ranting when people formally ask for my opinion. So I wanted to write a short post about why this is clearly the way forward for Direct Project adoption.
If you have anything to add to my bullet points, email me at fred dot trotter at that email service that google runs.
There are two definitions of the word “Hacker”. One is an original and authentic term that the geekdom uses with respect. This is a cherished label in the technical community, which might read something like:
“A person adept at solving technical problems in clever and delightful ways”
While the one portrayed by popular culture is what real hackers call “crackers”
“Someone who breaks into other people computers and causes havok on the Internet”
People who aspire to be hackers, like me, resent it when other people use the term in a demeaning and co-opted manner. Or at least, that is what I used to think. For years, I have had a growing unease about the “split” between these two definitions. The original Hackers at the MIT AI lab did spend time breaking into computer resources… it is not an accident that the word has come to mean two things.. It is from observing e-patients, who I consider to be the hackers of the healthcare world, that I have come to understand a higher level definition that encompasses both of these terms.
Hacking is the act of using clever and delightful technical workarounds to reject the morality embedded default settings embedded in a given system.
This puts “Hacking” more on the footing with “Protesting”. This is why crackers give real Hackers a bad name. While crackers might technically be engaged in Hacking, they are doing so in a base and ethically bankrupt manner. Martin Luther King Jr. certainly deserves the moniker of “protester” and this is not made any less noble because Westboro Baptist Church members are labeled protesters too.
Like protesting, Hacking is all about taking a certain set of ethical issues that are important to you, and then performing an act whose central purpose is to restore ethical balance. People with screwed up ethical compasses will give good protesters and good Hackers a bad name.
I like this broader definition because it really shows that Hacking is not at all limited to technology. It relates to “systems”, as long as the “system” is complex enough to encode moral notions. This means that protesting is really just a special kind of Hacking, in fact we might rename it “public opinion hacking”.
Consider Richard Stallman. Stallman realized when he couldn’t get access to printer control software because of a proprietary license, that the license itself was encoding something he had an ethical problem with. Rather than accept that embedded morality, he created a workaround solution (copyleft licenses) that created an alternative with an embed morality that he could live with. The system that Stallman was hacking was copyright and licensing and the modern Open Source movement is the result of this hack.
The notion that technology and other complex systems can have moral notions embedded is neither new, nor mine and I recommend Lessig’s Code and Other Laws of Cyberspace for a full discussion.
I came to this conclusion as we renamed our “meaningful use” book to “Hacking Healthcare“. David Uhlman (my coauthor) and Andy Oram (my editor) seriously considered “Hacking Healthcare Software”, as an alternative title. But in our discussions it became apparent to us that David and I were really hoping to teach people how to use software to change the Healthcare system itself. The software was merely the type of hack that we were proposing, rather than the system being fixed with the hack.
Any efforts to hack healthcare should be embraced because the default settings on the Healthcare system really suck.
We have too many medical errors. We have overtreatment, undertreatment, fraud and disconnected care. Worse, until very recently, we had incentives that were virtually guaranteed to make these problems worse. These problems are merely symptoms of the wrong set of morals being encoded into the healthcare system.
Which leads me to introduce Karen Herzog to you. Karen makes my efforts to hack healthcare look somewhat childish. Like other, more famous e-patients like e-patient Dave and Regina Holiday, Karen, along with her husband Richard Sachs refused to accept the default settings of the healthcare system when their daughter Sophia was born with a rare genetic disorder. Shortly after Sophia’s birth, Karen and Richard were informed that their daughter disease was incurable and that she was dying.
The default settings for the healthcare system in these circumstances could not have been worse. Karen and Richard were offered occupational therapy, physical therapy, grief counseling and “when she turns blue let us know..” by their doctors in a manner that was obviously code for “we cannot help you, sorry for your situationa but get out of our hair”. Karen and Richard refused to accept this. They did go home, but rather than allow the healthcare system to “wash their hands” of Sophia they created a garden. This literal garden was the first step in creating a community of care that re-engaged their doctors, who were themselves feeling hopeless and overwhelmed a safe environment to try to make Sophia’s life better and to seek a cure. Like all of the greatest “Hacks” Karen and Richard repurposed simple solution and made it apply to a problem that was regarded as unsolvable. They created a literal space that was so welcoming that it inspired collaboration in a group of clinicians that were not used to collaborating worked beautifully. They found ways to make it obvious that Sophia’s space would not be a deathbed, but a different kind of space altogether.
Eventually Sophia died, but only after receiving care that was orders of magnitude better that what could have been accomplished if Sophia would have been hospitalized full time. Hundred of clinicians, friends and family came together to make Sophias garden into a success, in a collaboration that never could have occured inside the walls of any given healthcare institution.
This success was hard-fought. Together, Sophia, Karen and Richard experienced just about every significant problem that patients and caregivers can have. For each hurdle, Karen and Richard continually refused to accept the “default settings” that the healthcare system offered, by responding with hack after hack.
I am humbled to be speaking opposite Karen. Since Sophia died, Karen and Richard have pivoted their design group into one of the preeminent “Patient UX” shops in the country. They have leveraged their troves of poor experiences with the healthcare system, and their methods of working around them, into a series of fundamental insights about how to improve patient experiences with technology and design. They are my default recommendation for design work in the healthcare space.
I have been watching what e-patients like Karen and Richard are able to accomplish for years and I have come to realize that in many ways, they are far more deserving of the honorific of “Hacker” than the bozos who deface websites to make political points. In much the same way that the recognition that MLK Jr was a protester, makes it embarrassing that we have to label the Westboro church members with the same label.
Like the original Hackers who built the Internet and the first computers, e-patients are blazing a trail through the healthcare system. Decades from now we will look back on this class of patient and realize that they remade healthcare by simply refusing to accept the aspects of the healthcare system that typically suck. In the future, when the new norm for doctors is respect patients enough to actually let them finish sentences, we will have this generation of e-patients to thank. Much the same way that we recognize that our iPhones and Androids would not be possible without the pioneering Hackers of the *nix community.
Karen and I will be doing a “dueling keynote” at Health::Refactored, asking each other difficult questions about the state of the art in design and technology in healthcare. I hope that the audience will learn some tidbits from me about how to work with software to help fix healthcare, but I think I have made my case that Karen will be the real healthcare Hacker on the stage.
I love hackathons.
I love winning them. I love competing in them. I love winning them. I love judging them. I also love not losing them.
This weekend, I am acting as a mentor to the first Health 2.0 hackathon in Houston Texas. As far as I know (which is not that far, really) this is the first hackathon in Houston to be focused exclusively on healthcare. Serving as a mentor rather than having the opportunity to directly win might seem counter intuitive, given how competitive I am. But I have had complaints about being a “professional” Health IT expert entering these contests, and as one of the organizers of the event, I do not want to be seen as unfair. This was a hard decision to me because in most cases, if I have to choose between winning and being unfair, I choose winning.. but my Houston Health 2.0 co-conspirators prevailed upon me this time…
I do well in hackathons because I know how to avoid the number one pitfall in healthcare hackathons: It is too tempting to make toys.
To really rock a Healthcare Hackathon you have to have a real strategy to build something that will make a difference, but something that you can still prototype in two days. Here are general thought strategies that have worked for me:
Here are some ideas that I will be pitching to participants to this weekends hacking contest. If I can find geeks with the required programming skill-sets and the team to ensure that they have the clinical and design backup that they need, I think these are all doable in two days.
Medical students are the only ones who understand the problems in medical school. I have designed a hack that will allow us to use big data on them directly to discover and fix the issues with our process for making doctors. I think this will require a team who can code in cross-platform Java… but a web-platform programmer could be tolerated in a pinch. SQLlite experience is a plus.
Every healthcare conference has a back channel, and in my experience at healthcare conferences, many of the real experts are in the crowd tweeting. Conversely the people who line up to ask questions at a microphone are unvetted, a tragic portion of those who ask questions are actually pitching their own projects, or exercising an obsession, or asking a stupid question (and yes… there is such a thing as a stupid question… or at least there are many morons who feel comfortable wasting my time with questions). I am pretty sure it will require something like Node or Pythons Twisted, but I think we can use Twitter to hack health conference Q&A for the better….
I am interested in creating tools that use Geocoding and QR codes together to motivate health. I need IOS and/or Android developers for this one.
Lastly I am interested in the ways that e-patients tend to favor twitter and I might be interested in developing an e-patient specific twitter tool. Need to code in a web-friendly language.
The QS community very clearly needs a specific tool that I have gotten alot of requests for. You must know either hardware interfacing (usually C or C++ for usb drivers etc) or web authentication (OAuth et al)
One of the API sponsors for this hackathon is Ask Ziggy which is essentially a “Siri as an API” for app developers. Its a clever idea and there are lots of possible uses here… no specific technical requirements other than to us this API.
This is of course, our own data set.. and you can read about it at the main DocGraph site.
I hope these are pretty vague ideas. I intentionally am leaving out the critical “how” part of each idea!
I hope this list is enough to spark some interest and get developers to attend this conference. I will not be the only one pitching ideas, and teams attending with pre-baked ideas typically do well at these kinds of events. Still if you want to use my ideas, and hear me explain how to do them and why they will work then you need to meet my specific criteria. First, you must be willing to develop in the open, and under Open Source licenses. I am giving you a hackathon winning idea for no money. (and I am fairly certain, given that I have judged more health 2.0 contests than anyone else) Even if you do not win the contest, these ideas are so good that I will probably be able to make you fairly famous in the Health IT and Health 2.0 communities.
By working on my ideas you kind of hedge against losing at all. If you are able to pull of the projects, then I will give you credit publically for your awesomeness, which is valuable to anyone looking to make a name. For this valuable insurance service, I need to be able to start from where you left off if you decide to abandon the project after the hackathon… That means github and the FOSS license of your choice (I like the AGPL)
You also -must- have the skillset that I require for a given project for me to give you the details on a project. I cannot have my best ideas just “out there” for people to run off with!! I am pretty sure that I have at least one project for every kind of developer that I can think of listed above. If I could do all of these ideas myself with my programming skill set.. guess what… I would have already done them or I would save them so that I could win some other hackathon! Each of these projects leverages a very specific hack of some kind. Either hacking hardware interfaces, user expectations, software design, data levers or something like. After I describe the “how” of each project there will be an “aha/wow” moment, when you think “We didn’t I think to do that?” (Note I felt this way after seeing IFTTT for the first time). If I am handing you a “wow” world-changing hack then I have to know that you will make us both look awesome when you pull off the hack. Don’t worry if you do not have a specific skillset I define here. I have lots of other ideas based on what you are good at! This especially applies to designers and other artistic types and to clinicians!! All of these projects could use clinical/design help!!
If you have not signed up yet, then I would get over to the signup page now. So far, every Houston Health 2.0 event has sold out so far, and we expect this one too as well. I have some pretty awesome project proposals but I can tell you now that these will just be a few of the awesome ideas that we are bringing to the table for this Hackathon. Most importantly, if you already have a project in mind, then you will be able to find a team to help you hack on your project! All you need is alot of motivation, a little skill and a willingness to collaborate. Or even just one of those three would do…
Looking forward to seeing you there!!
There are two events coming up soon that you do not want to miss.
The first is not this weekend but next: The Houston Health 2.0 codeathon is happening (March 23-24 at Platform in Rice Village)
The second is Health::Refactored from the Health 2.0 conference series. That happens on May 13-14 in Mountain View, CA.
I will be acting as mentor at both events. We are specifically looking for e-patient mentors, so if you are interested in this role, please let me know.
Also, I need to start promoting these different conferences and code-a-thons that are friendly to the “Hacking Healthcare” approach… what is the best way to promote and maintain different events on the web? Is there some kind of automatic event-to-email-to-RSS-I-don’t-have-to-think-about-it tool that is popular for tracking a series of events?
Go to these two conferences. They will be awesome!
I just wanted my readers to know (I do have readers… don’t I ) that Regina Holiday is hosting a crowdfunding event on medstartr
It is the cheapest way I know of to get a copy of an original from Regina.
I am happy to announce with psuedo-permission from the Society for Participatory Medicine (by which I mean that they have not asked me not to do this) a Twitter badge for HIMSS 2012.
There are a handful of the epatients who are attending this years HIMSS (alas, I am not among them) and they have agreed to play a game to help get to know the e-patients. Those who complete the game get to have a digital version of the epatient badge for HIMSS12.
The game is simple. Each of the following e-patients have given me a riddle that they will answer for you either over Twitter, or in person. Plus I have given each of the e-patients attending the conference a super secret code word. That means that you have to either figure out the riddle on your own, use the riddle as an excuse to introduce yourself to each epatient over twitter, and you have to find and post a picture of yourself wearing the S4PM badge!
Then I will generate a digital badge for you that you can use on your twitter background, or any you can use in any other website where you can post an image. The digital badge will have your twitter username written on it, to prove absolutely that you have earned the badge.
This badge will be issued only for people who complete this puzzle during HIMSS. We might issue different epatient badges in the future, but this one will never be issued again. This is truly a once in a lifetime opportunity. Everyone you know will be jealous of the small graphics file that you acquire here. Truly, your completion of this puzzle will be a story that you can relate to your grandchildren (to put them to sleep).
Seriously, this might be a fun way to get to know some new people at HIMSS and to help spark discussions about patient engagement at HIMSS. I wish I could be there in person, but at least I can provide you all with something fun to do while you are there…
You can get the S4PM badges from the Relay Health (#3618) or MedSeek (#1345) booths, or by attending the S4PM Wednesday lunch meetup or one of the following epatient events at HIMSS.
Wednesday – @ReginaHolliday: #Thewalkinggallery meets @ ECollab Forum Wed 2-22 Venetian Sands, Bellini 2102, Level Main/Level 2 6-7:30 pm
Thursday – eCollaboration Forum http://www.himssconference.org/ecollaboration/default.aspx with a variety of speakers, among them: Brian Ahier and e-patient Dave
Thursday – Engaging Consumers in their Digital Healthcare http://www.himssconference.org/Future/default.ASPX with Regina Holliday as keynote speaker
Tweet the picture of yourself wearing the badge for bonus credibility, but all I need is the pictures URL as proof.
To play, all you have to do is complete the form below!
Have a good time!!