Every day I experience life in the world of healthcare IT, supporting 3000 doctors, 18000 faculty, and 3 million patients. In this blog I record my experiences with infrastructure, applications, policies, management, and governance as well as muse on such topics such as reducing our carbon footprint, standardizing data in healthcare, and living life to its fullest.

I was posed a simple question - If I had infinite resources, infinite time, and no legacy compatibility issues, how would I design the electronic health record of the future?

Here's my answer:

GeneralThe web is the way. Given the 24x7 nature of healthcare, the need for physicians to be in many physical locations, and the multitude of clinician computing devices, the ideal EHR should be web-based, browser neutral and run flawlessly on every operating system. I highly recommend the use of AJAX techniques to give physicians a more real time interactive experience. Client/Server may have some user interface advantages, but it's just too challenging to install thick clients on every clinician computing device. Citrix is an expensive and sometimes slow remote access solution. Native web works.

Data in medicine is stored hierarchically i.e. a patient has multiple visits with multiple labs, with multiple results. This is a tree of data with the patient as the root and the lab values as the leaves. Using a hierarchical database such as Intersystems' Cache ensures that data for clinical care is stored in this tree format and thus can be very rapidly retrieved, ensuring fast response times for clinician users. For population health, clinical research, and performance reporting, relational databases work very well. Thus, I recommend a hierarchical database for the clinical care applications and relational data marts for the research applications.

The ideal EHR should incorporate decision support in laboratory, medication, and radiology ordering. EHRs should include "Event Driven Medicine" alerts about critical clinical issues and patient specific reminders about preventative/wellness care. Event Driven Medicine is the transformation of data into information, knowledge and wisdom based on decision support, business rules and timely notification of clinicians.

The EHR should include an easy to read clinical summary of all active patient problems, medications, visits, and labs and should be able to export this summary to personal health records such as Google Health, Microsoft Health Vault and Dossia.

Problem ListsProblems should be entered via an electronic pick list of vocabulary controlled terms using SNOMED CT. The community of caregivers - PCPs, specialsts, ED physicians and hospitalists should be able maintain this problem list collectively, using social networking type tools. Call this Wikipedia for the patient. All caregivers should be able to associate notes and medications with entries on the problem list, making it easy to filter notes by problem and discontinue medications that are problem-specific when problems are resolved.

MedicationsMedication Management features should include e-Prescribing for new medications, automatically linked to payer-specific formularies, electronic real time pre-auth/eligibility for high cost therapies, links to lifetime medication history from retail pharmacy and payer databases, and safety checking for drug/drug and drug/allergy interactions. Pharmacy initiated renewal workflow would reduce calls to the physician's office to refill medications.

Ideally, medication reconciliation features should include pre-population of the medication list based on the lifetime medication history from retail pharmacy, payer databases and personal health record applications. Using the same social networking type approach as mentioned with problem lists, all caregivers should be able to update/change/edit/comment on patient medications to keep them current. One click quick picks of commonly used medications should be available to make ordering Tylenol as easy as ordering books on Amazon.

AllergiesAllergies should be recorded by caregivers using vocabulary controlled entries for therapeutics, foods and environmental substances. Reaction type and severity should be codified as well as the identity of the allergy observer/documentation source i.e. did the patient self report that their Mom saw a rash to pencillin 30 years ago or did an ICU nurse watch the patient anaphylax to pencillin?

VisitsEach visit should be documented with a reason for visit (symptoms or problem), a pre-existing condition flag if the patient has had this before, a diagnosis, a list of therapies given, and the followup arranged.

NotesNotes should be entered via structured and unstructured electronic forms. All text data should be searchable, so that physicians can easily locate old notes. Templates that are disease specific and macros that are specialty specific should be available to make documenting easier. Voice recognition for automated entry of free text should be available. Workflow for signing notes and forwarding notes to other providers should be easy to use.

Laboratory resultsLaboratory results should be displayable in several ways - by date, by class of lab, by single result trended over time and in screening sheet format. Screening sheets are lists of disease specific lab results combined with decision support. For example, a diabetic screening sheet would include glucose, hemoglobin a1c, lipids, recent eye exam results, podiatry consults, and urinalysis. Alerts and reminders should be generated based on disease state, lab value, and trends.

As results are delivered, especially important results, clinicians should electronically sign an acknowledgement of lab result notification, ensuring that appropriate next steps are taken for patient care.

Radiology resultsAs mentioned in my recent blog on image management, all "ologies" should be stored in one place in the EHR and all should be viewable with a single electronic viewer. Radiology, Cardiology, GI, Pulmonology, Echo, Vascular, and Gynecology images should be easily viewable and these images should be managed according to business rules i.e. retained as required for medical record compliance, archived when no longer relevant etc.

OrdersElectronic ordering should include medications, Oncology Management, Laboratories, Radiology and general care (i.e. ordering home care supplies, wheelchairs etc). Orders should automatically be routed to the department and staff responsible for executing them.

Health Information ExchangeThe EHR should be able to retrieve medication lists and clinical summaries from outside institutions as part of local/regional healthcare information exchange. EHRs should be able to send data to personal health records and receive patient entered data, especially telemetry data from home devices like glucometers, from personal health records.

Data MartsEvery night, data from the EHR should be exported to data marts for appropriate use with IRB approval for clinical trials, clinical research, population health analysis, performance measurement, and quality improvement.

At BIDMC, we're continuously improving our systems and we're well on the road to achieving much of this functionality. Of course, we'll never be done because the goal of the ultimate electronic health record is a continuously evolving target.

17 comments:

I applaud your recognition that clinical data is best stored in a hierarchical database, such as Caché, and while relational formats are well-suited for the data marts. But IMHO, describing classic nightly exports from EHRs to data marts is simply outdated thinking and bad process. It is well past the time for those EHRs to put in place a _real_ data dictionary that can:

1 ..accurately depict the definition of each element;2 ..enforces the physical and logical disposition of the content, not deterministically arrived from custom program algorithms;3 ..allow for evolution to occur naturally without code re-writes; and 4 ..provide native relational access to the same data hierarchy with real-time access -- regardless if it spans decades for clinical research or today's patient census in a dashboard.

Today's computing platforms easily support the Caché objects paradigm and both have matured to a point where this can be enabled -- without legacy compatibility issues -- to support your vision and ideals for EHRs. I would welcome such as design discussion with you.

Nice analysis, with some potentially faulty technology conclusions. It really bugs me when a CIO demonstrates low-level technology-of-the-day bias. Yes that can be pragmatic, but it can also be unnecessarily restrictive.

"Given the 24x7 nature of healthcare, the need for physicians to be in many physical locations, and the multitude of clinician computing devices," I would agree that "the web is the way," but not in the literal sense that you mean it. Take a look at Microsoft's Live Mesh for a more holistic approach to addressing this reality across devices, across organizations, in many physical locations, on the web AND on the desktop.

I personally think the jury's still out on hierarchical databases, and I find the "healthcare is different" argument to be similar to thinking the sun revolves around the earth. I hope you don't also think that Mumps is a superior programming language uniquely suited to healthcare...

Sorry for the rant. In general I find your perspective to be quite refreshing and pragmatic in the world of healthcare, but the AJAX and Intersystems Cache comments struck me with too much of a tone of coolaid-drinking.

First, as I watch the whole freakin' world of software evolve toward the "platform as a service" concept, I no longer have any doubt that the remaining advantages of non-Web architectures are just going to wither and die. I've seen it happen in two previous industries. Can you say "disruptive"?

There are just too many advantages. Keep an eye on Ted Eytan's blog, and check out Susannah Fox's "7 words of wisdom" post after attending Health 2.0 last month, where the last two words were "Go mobile."

She made a really good point about the large number of people in the world who don't have a computer but do have a cell phone. We already have Bluetooth and WiFi glucose monitors, etc ... it's soo easy to see which direction things are heading.

Salesforce.com CEO Marc Benioff gave a pretty compelling pitch Tuesday about this "platform as a service" concept. He cited Eric Schmidt saying (1993) "When the network becomes as fast as the computer, the computer hollows out and spreads through the network." That was before the Web hit and bandwidth went nuts.

Now that handhelds are getting more powerful and platforms (like Google and Salesforce) are getting mobile-smart, applications are being designed so they just don't care what the terminal is. It's inevitable where that's going to end up.

I just see all kinds of current barriers coming down in the "foretellable" future. Heck, Kevin Kelly of Wired recently pointed out that the Web just passed its 5000th day sometime in '07.

As with any disruption, I'm sure the far side won't look like this side. Disruptions always trash the values of the old system, to get advantags the old system didn't offer, and then catch up. Meanwhile people defending the old values scream. (I've been one.)

I'll also predict that someday (soon?) we'll cross a tipping point where suddenly it becomes easier for docs to get their jobs done the new way. THAT oughta create some momentum.

I'm sure glad to be in the game. And I'm glad the concepts are being iterated out in the open like this - something that wouldn't have been imaginable 5,000 days ago...

Nice post with some excellent points made. In full agreement that Web-based solutions will be the future in healthcare IT (HIT). With our still abysmal rate of adoption of HIT among physicians, Web-based EHR as the only solution that will accelerate adoption (along with some form of incentive) for it provides the physician the ability to:1) Meet their criteria for low entry/adoption costs.2) Meet their criteria for low support costs.3) Help them get online and maybe even start to provide a higher level of service, via e-Consultations, which will, in my belief, be reimbursable by all payers within the next 1-2 yrs.4) Insure they don't get left in the dust.5) They will be able to expense the cost, rather than a major capital outlay.

There will be some issues with an SaaS EHR (actually your post is more about an EMR), such as limited ability to customize, but the benefits will outweigh such limitations.

The only quibble I have with this post is that you refer to it as an EHR. I operate on the assumption that an EHR=EMR+PHR. There is very little in your EHR vision that considers the consumer. This is a major flaw in your hypothesis for the future will have a consumer that is much, much more engaged than they are today. Not accounting for such results in a parochial, clinician vision that does not reflect future reality. And we are talking about the future, right?

This is truly amazing. Not faulty technology in any way. Very insightful and perceptive all the way John. We have created such an EHR using Cache. You are absolutely right. We are shocked at how close you have described our system. We have spent the last year creating almost the exact same system you have described and only Cache could make it possible. I am not advertising Cache, I am just telling the way it is. Why do I say that? Mainly because Cache has at the core the composite class structure and ordered lists required to pull off such an architecture. And that is just the beginning.Event Driven Rule Processing? Right on, that is the way of the future for decision support.John you can be sure we will keep everything you said in mind as we continue on.

I agree with a great deal of your assessment on the ideal electronic health record. In your opinion, how far do you feel we are from the ideal? It seems to me in many cases the technology to do many of these things you speak about is there or just about there. More of the challenges I see are related to the organizational and political hurdles with making it all integrate and getting everyone to play nicely.

I attended a guest lecture at the University of Waterloo given by William Albino, CEO of Ontario's SSHA, "Smart Systems for Heath Agency". Bill is a former executive of EDS and now leads this commercial agency of the Government of Ontario (Canada) that is tasked with implementing Electronic Health Records in the province.

In the Q&A, I made the provocative suggestion that "I feel that I could accomplish this task as a Facebook application built by two teenagers over the course of a weekend" and asked him to what degree SSHA was considering social networking standards such as Google's Open Social in their application development.

I got a chuckle from the audience, a smile from Bill and the typical "we've got to be concerned about security" response I expected.

To me, the "friends" paradigm is the binding structure that makes EHR's useful and productive. I'm friends with my self, with my caregivers, with the chronic disease management devices that check my levels...my family physician is friends with his referral partners, with his hospital...my labs are friends with their community of coverage, etc..

I am excited by your depiction of the ideal EHR and your conclusion that "the web has it".

It's not an accident that the hierarchical and free-form (aka schemaless) Mumps database has been able to support the electronic health record so well for so long, and it's interesting to see that those same unique features (for long derided as "old fashioned") are now coming into their own again as the demands of delivering databases on an Internet-scale begin to bite. See this blog which sets out the reasons in more detail.

I agree with a great deal of your assessment on the ideal electronic health record. In your opinion, how far do you feel we are from the ideal? It seems to me in many cases the technology to do many of these things you speak about is there or just about there. More of the challenges I see are related to the organizational and political hurdles with making it all integrate and getting everyone to play nicely.