Building Boats and EHRS

Imagine that you want a boat. You tell someone to build or buy you a boat, and tell them to send you a bill. What would you get? A kayak? A windsurfer? A boat for waterskiing? A sailboat. A party boat? A cruise ship? A submarine? A battleship or destroyer? You probably would not get what you want. Very likely you would end up with something expensive – that you cannot use.

Before you build or buy a boat, you need a defined goal and a process:

  • Define the parameters. Who will use the boat? What does the boat have to do?  Carry passengers? How many? Carry freight? How much?  How far? How fast? Ocean? Lake? River?
  • Identify the constraints.  How long does it have to last? How much is it worth and how much can you spend? What are the legal implications? Where will it be stored and how will it be transported and maintained?
  • Find people who know how to build or buy THAT kind of boat.
  • Have the boat experts work with the prospective boat users (who may not be the purchasers or owners) to plan or find the boat.
  • THEN you can build or buy a boat that will meet the needs of the users and you won’t be stuck trying to pull a waterskier with a kayak.

The same applies in medicine. If you are the leaders of a medical institution and want an electronic health record, you cannot simply pay someone to write it or buy it. You need to start by asking the users to define what it is do and how it is to do it.

Categories: Uncategorized

7 replies »

  1. It is very well noted that it is necessary to first interview the end-users of the software. This is the step that is often overlooked in software development. What is also important is instructing clinicians on the use of EHP.
    Based on my practice, if you miss this, it will result in great difficulties in further practice. We have collected a heap of all the tips for implementing software in clinics in this article: https://yalantis.com/blog/why-create-your-custom-telehealth-solution/

  2. The same applies to any software product you try to develop. That’s why you have phases like requirements, design and presentations to clients. Building a product without an exact definition of what you want to achieve, is a complete waste of money and time.

  3. Seems like vendors can build boats (EHRs). Thing is, not only physicians suffer from these glorified billing systems, but the major EHR vendors are starting to give up on EHRs as well. They recognize that caregivers need the systems built around their workflows, not around administrative procedures at the core, which initiates useless and non-reimbursable clicking. At ScienceSoft, we dived more into what the EHR vendors think and plan to change their approach to the central system in technology-powered care delivery: https://www.scnsoft.com/blog/ehr-is-becoming-a-dirty-word

  4. Are you for real? Should drivers have no input about how their cars work or what kind of vehicle they drive every day? Maybe you wouldn’t be so happy if Big Brother issued you a Personal Mobility Device designed by accountants and environmentalists who never drove a car themselves, and, just to make it more interesting, if that contraption could only make left turns, or wouldn’t allow simultaneous use of headlights and windshield wipers? That’s not far from what it’s like to use some of the EMRs out there!

  5. This thinking is upside down. Except in boutique practices accepting no insurance or government payments, physicians and other providers, the end users, should have no more than a minor voice in Electronic Medical Record design. The payers and patients, represented by data scientists who use the aggregate data, should decide on EMR design. The low quality data collected today conceals so much wrong with healthcare.