Making engineering part of healthcare’s work
An institution can buy a platform and still lack the capacity to build. Engineering needs a place in the everyday work of care.
My recent attempts to help leaders work with Databricks have made an older argument feel immediate: healthcare needs people who know how to build things, and it needs to make room for them inside the institution.
That was what stayed with me from Building a Better Delivery System, the 2005 report from the National Academy of Engineering and the Institute of Medicine. The report called for a partnership between healthcare professionals and systems engineers, with care delivery understood as a set of interdependent activities. More than two decades later, I still find that argument useful when trying to move from interest in a platform to the practical work required to use it. 1
A platform provides capabilities. Someone still has to determine what the organization is trying to change, establish whether the data describe that work, build something people can use, and take responsibility for keeping it useful. Those obligations do not disappear when the software is purchased.
The communication barrier is only part of it
I have seen clinicians work well with people who understand products, customers, and running businesses once they develop a shared language. Engineering introduces another vocabulary: requirements, interfaces, failure modes, validation, maintenance. A healthcare administrator who is comfortable translating between a clinician and a product manager may have had fewer opportunities to work with an engineer.
That is a real barrier, but I doubt it explains the whole problem. A team can learn to communicate and still lack a role, budget, or career path for the person it needs.
Compensation is one possible obstacle. Engineering salaries may fit poorly within existing nonclinical pay bands, especially where there is no established engineering job family. Conversations I have had with engineers often return to better pay elsewhere and leadership that supports building new things. These are observations from my own experience, not a survey of healthcare employers. They suggest a question worth investigating: does the institution’s employment structure support the capability its strategy calls for?
The same question applies to authority. Hiring an engineer is less useful if that person enters only after the workflow, platform, and deadline have already been decided. Engineers need to help define the problem and test assumptions while those choices can still change. In return, they need to learn from the people who deliver care and live with the consequences of a design.
Institutional responsibilities are built over time
Healthcare already has engineers. Clinical engineering, facilities, informatics, improvement, and software teams all contribute to the work. My concern is whether engineering care delivery has a durable institutional home, with people and resources that persist beyond an individual project.
History helps me think about that distinction. The Rockefeller University Hospital opened in 1910 as the first U.S. hospital devoted specifically to clinical research. That example shows an institution organizing itself around a purpose that needed dedicated people, space, and support. It does not mark the beginning of medical research. 2
Hospital management engineering also has a longer history than contemporary discussions of digital transformation sometimes suggest. HIMSS’s institutional history identifies Earl J. Frederick as its first full-time hospital management engineer in 1952, jointly employed by the Cleveland Clinic and St. Luke’s Hospital. The history describes subsequent departments and professional organizing around improving patient services and reducing costs. 3
What interests me is how a field becomes part of institutional life. Research and nursing have communities, training pathways, conferences, leadership positions, and forms of recognition that help sustain their work. Engineering also has professional communities; the question is how firmly the relevant capabilities are embedded in a particular health system.
In teams I have worked around, clinical participation is often an expected part of the arrangement, including on analyst teams. Engineering participation can feel more contingent. I want it to become easier to justify before a project runs into a problem that requires it.
A digital twin still needs an observable system
I have been moving toward engineering through my work as an analyst at Penn, my courses at Hopkins, and external projects that have found users. That experience has made me more interested in what happens between an ambitious idea and a working tool.
Digital twins make the gap concrete. A model intended to represent a real operation needs a dependable relationship to that operation. If the relevant events are not recorded, the definitions are inconsistent, or nobody has time to collect the missing information, enthusiasm for the model cannot repair the missing foundation.
In work I have been involved with, interest in digital twins has coexisted with missing data and difficulty securing support to collect it. I understand the competing priorities. Leaders may see an area that appears to be performing well and reasonably focus their attention elsewhere. Yet incomplete measurement can be the reason the area looks settled. We need enough visibility to distinguish acceptable performance from a partial view.
That does not mean collecting every possible data point. It means agreeing on the decision the model will support, identifying the observations needed to support it, and deciding who can maintain those observations. An engineer, an analyst, and a clinician may each see a different part of that dependency.
- Observe the work
Clinicians and operators identify the decision and the constraints.
- Make it measurable
Analysts and engineers check definitions, gaps, and data ownership.
- Build and test
The team tries a bounded change and inspects its effects.
- Keep it working
An accountable owner maintains the tool and brings findings back to the team.
What the team learns returns to the next observation.
An operating proposal: roles overlap, and the loop needs time, access, and continuing ownership.
AI may make some engineering and statistical techniques easier to approach. It may help more people write code, explore data, or build a prototype. I am optimistic about that. But a prototype still needs someone to ask whether its assumptions fit the work and whether its output deserves to influence a decision.
Trust begins with useful work
What has helped me is leading by example and earning trust through work that people can inspect. I want to become someone whose involvement makes a project go better: someone who notices a missing dependency, makes an assumption testable, or leaves behind a tool another person can maintain.
Small contributions matter. A clearer definition, a reliable data check, or a more understandable handoff can make the next improvement possible. They also help a team understand what engineering adds without requiring everyone to adopt its vocabulary first.
But goodwill cannot be the whole employment model. An institution that relies indefinitely on a few people building beyond their formal roles makes continuity fragile. It should be possible to turn demonstrated usefulness into a supported responsibility, with time to maintain the work and a career that rewards doing it well.
I love healthcare, including the fact that engineering does not define its whole culture. Its purpose is care. The place I am looking for is one where building and maintaining better systems becomes an ordinary part of serving that purpose.
Health systems will continue to depend on outside technology companies. They also need enough internal engineering capacity to understand what they are buying, shape how it fits, and remain accountable for the work around it. That is what I mean by making engineering part of healthcare’s work: giving people who build a lasting place beside the people who care.
Notes
- National Academy of Engineering and Institute of Medicine. Building a Better Delivery System: A New Engineering/Health Care Partnership (2005). Report and publication information. The report supplies the systems-engineering argument; the workplace observations and proposals here are my own.
- The Rockefeller University. “The hospital turns 100” (December 3, 2010). Institutional history.
- HIMSS Legacy Workgroup. History of the Healthcare Information and Management Systems Society: 1961–2006 (2007), pp. 4–5. History PDF. The Frederick milestone is attributed to this institutional account.
About the illustration
