Start with the problem, not the technology
The most expensive decisions in healthcare IT are made before the first requirement is written.
Every healthcare organization we have worked with has a technology it regrets. Rarely was it a bad product. Almost always it was a good product bought to solve a problem nobody had written down. The demo was impressive, a peer organization had it, a vendor promised an outcome, and eighteen months later the system was live, the staff were trained and the original problem was exactly where it had been.
The discipline that prevents this is simple to state and hard to practice: before any discussion of technology, write down the operational or financial problem in a sentence that a clinician, a finance leader and an engineer would all recognize. "Patients discharged on Fridays are readmitted at twice the rate of patients discharged on Tuesdays." "Our care managers spend forty percent of their time looking for information that already exists in another system." "We will lose this contract if we cannot report these measures by this date." A problem stated this way has a measurement attached to it, which means the organization will know whether the eventual solution worked.
What this changes
Starting with the problem changes the shape of the conversation with vendors, because the organization is now evaluating a claim rather than admiring a feature. It changes the roadmap, because initiatives can be ranked by the size of the problem they address rather than by who argued loudest. And it changes what "done" means: not go-live, but the day the measurement moves.
It also makes a surprising number of projects disappear. When the problem is written down, it often turns out to be a workflow, a staffing or a policy problem that technology would only have decorated. Saying so is part of the job. An architecture partner who recommends technology for every problem is not an architecture partner; they are a sales channel.
How we practice it
Our engagements open with problem framing, and we hold the framing fixed while options are explored. Business use case discovery, solution validation and value proposition development all exist to serve that one sentence. Only once the problem, its measurement and its constraints are agreed do we talk about platforms, standards and vendors. The sequence is the method.