I recently had somewhat of an epiphany. I had been speaking to a formal colleague who commented on the efficiency and comfort and range of capabilities of the electronic medical record (EMR) that I wrote and is still being used by my previous employer. He asked me how difficult it would be for me to take such a system and distribute it to others. I explained to him that my style of programming is one of custom design. As such, each system I build, and each component of each system, is customized to the specific needs of the end-users. I would not offer my EMR in its present form to a gynecology service, but I would use portions of it and then build a custom interface and tools for the new service.
The following link comes across as very technical. But it’s basic message is the following – software today should not be built from scratch, but as much as possible should be “assembled” from a collection of calls to existing, readily accessible, often web-based tools that are specific and effective at a certain task. One of the examples that the article above refers to is using one packaged external software system for reading the surface of a credit card, and then using another packaged external software system to send a bill for services to the credit card company, using the information extracted by the first system.
And this is the foundation of my idea. In the States today, writing a new EMR is extremely difficult for multiple reasons. The existing EMRs that presently own the lion share of the market, tend to be geared towards administration and billing, rather than clinical use. That is why so many doctors complain about using EMRs in the US.
In my EMR, for example, the interface for the doctors is totally geared towards recording clinical information. There is no part of the doctors’ interface that openly relates to administrative issues. Behind-the-scenes, such information may be recorded and saved. But the doctor doesn’t deal with this. The problem is that I cannot extract this part of my system and just plug it into another EMR. My system was built as a set of big units, and so are most other EMRs. But imagine how great it would be if you could mix and match parts of various EMRs to design something that was specific to your needs.
What the medical software world literally, desperately needs today is a collection of software packages that are readily accessible via the Internet, and that would allow someone to build an EMR in a fraction of the time that it takes today. This EMR would be assembled much more like Lego, rather than being written out, line by line, as software still tends to be.
For example, imagine a drop-down list that can be added to a blank webpage but that has contained within it, the entire, geographically appropriate, list of medications. This drop-down would automatically include an information button that would allow the user to view a detailed page of information about the medication. Obviously, there would be information about appropriate dosing, including specifics about how to give the medication to special cases like patients with renal failure and liver failure. This page of medication information would also include rules of use for patients who are pregnant or breast-feeding.
Imagine beyond this, that this little drop-down would include the option for accepting additional codes that specify the clinical status of the patient. So, when the program that uses this drop-down is actively running, you could specify that the patient is pregnant or has renal failure and so on. In response to this, the drop-down would display the full list of medications but would show the now forbidden options in red with a line through the letters.
For any individual company, designing such a specialized drop down takes a great deal of work. The frustrating part is that every single company that writes an EMR must build this specialized drop down from scratch. Sometimes, not rarely, such functionality involves so much code and so many tables of data, that no one wants to make any changes to it, once it has been completed. The fear is that a simple change might introduce some type of bug. As such, even when there is great clinical demand for changes, an EMR company may be very resistant to changing their software.
Let’s now say that an EMR company could pull out all of their own code/tables that allows a physician to choose a medication and replace these with a single line of code. This would be a revolution. Of course, it would be the responsibility of the company that has developed this drop-down (i.e. the component creator) to continue to improve the component and keep it up-to-date with new medications and changes in the rules of how to use existing medications. And that is why the users of such a drop-down would be paying a licensing fee for its use.
Imagine a component that allows you to write a full prescription. Or, a drop-down that includes every diagnosis along with a full description of the diagnosis (accessible via an included information button next to the drop-down). Sending emails and SMSes, generating discharge forms, displaying imaging studies, sending a consult – imagine all of these capabilities being available via a couple lines of code that can be added to any program.
I wholly admit that my focus is clinical but that some of the most complicated code relates to region specific administration and financials, not clinical interfaces. It might be that this non-clinical portion of the EMR would have to be coded line by line. On the other hand, it still might be that, say, five versions of an administrative system would be enough to cover all of the variations in billing needed across a particular country. So the EMR developer would pick one of the 5 administrative components that is appropriate to their clients
The point is that with this Lego approach, you can add and replace huge portions of functionality in seconds. I suspect that once the first version of such a system were to hit the market, other companies would immediately begin to create alternatives for individual components. So you could use the list of medications from one vendor and the list of diagnoses from another. The market effect would keep prices low for each component and in the end, everyone from developer to user to component creator would benefit. The major EMRs, despite their market share, would face serious competition.
How long would this take? How much would this cost? Who would need to be involved? How would the work be done? How would this be marketed? How much would the component creators charge? These are all excellent questions that I will not answer here.
Let me just say that this is big. This could change things. This could make it possible for someone to build a customized EMR for a small town in India in record time. And at the same time, it would make it relatively easy to design a massive EMR needed to manage a group of hospitals.
I want to point out that this is still different than open source EMRs that presently exist. While a programmer who is versed in the programming language of the open source EMR can adapt it and modify it to specific needs, this is still far more work and far less flexible than a component by component assembly, which is programming language–agnostic. Also, there would be a company behind each of the components, whereas open source software is maintained by the community and can sometimes be insufficiently supported.
Looking back, there is nothing mind blowing in what I have just described. On the other hand, no one these days (to the best of my knowledge) is using this approach for designing medical software. I definitely believe that there is a need for and a true desire for such a system. And I believe that it is possible to market such components in a business sustainable fashion.
I welcome your comments and ideas, but first and foremost …
Thanks for listening and Shana Tova.