For a sub-industry with so much money and attention being paid to it, I am surprised at how no one seems to be very happy with the results to date.
We are working with doctors to design a next-generation IT system. The comment doctors keep making regarding current electronic patient record management systems is that getting information out of them is like “ death by a thousand clicks ”. They tell us that the systems have plenty of information in them, but getting anything useful out of them is painful, tedious, and far less efficient than working with the old paper charts.
The conclusion to be reached is that these systems were designed by asking the wrong questions. The systems were designed by asking the question: “What data do you want to keep track of for the patient?” The question that should have been asked is: “What do we need to give you to be able to facilitate your medical decisions?”
This reminds me of the huge epiphany I had a number of years ago when developing our business rules- based architecture. As we were first evolving BRIM®, I realized that ERDs were designed to answer the question: “What is the best grammar to use to build a relational database?” UML was designed to answer the question: “What are the tools needed to build an object-oriented system?” Using a business rules approach, we figured out that the right question was: “How do I describe what I want my system to do?” Only after describing the functionality of the system described do I need to worry about how to implement it. I should not let the technology drive my thinking, I need to let my thinking drive the technology.
If you are asking the wrong question, you will never get a good answer.
So, what is the right way to think about health care IT? What is the right question?
First , we have to recognize that our system will not have a single customer. This situation rarely occurs in standard business systems, except at the margin. We may have both operational and managerial users, but they are still on the same team. With health care IT, we have at least three VERY different classes of users: Health Care Providers, Patients, and Payers (insurance companies, Medicare and the like).
Each of these user groups has very different needs. Moreover, the core use case is facilitating how these different user groups communicate with each other rather than simply supporting the users themselves. Therefore, the main questions our system should be answering are:
1) How do we help the patient and the doctor communicate with each other?
2) How do we help the doctor make a good diagnoses and treatment determinations?
3) How do we ensure that the doctor gets paid for providing service?
Everything else should support the answers to these three questions.
Leave a Reply