How to Destroy Health IT Innovation

Disclaimer: This is a satirical “how-to” for leaders who want to accidentally (or hilariously) crush digital health progress. If you’re trying to spark health IT innovationkeep reading anyway, because every “bad idea” below comes with a very practical fix.

Why Health IT Innovation Is So Easy to Break

Health IT lives at the intersection of patient safety, privacy, reimbursement, regulation, and legacy infrastructure. That’s a fancy way of saying: you’re building software on a moving train… while the train is also a hospital… and the passengers are on hold with their insurance. When innovation works, it improves care coordination, reduces documentation burden, opens access to records, and helps patients move across systems without dragging a paper folder like it’s 1997.

When innovation fails, it usually isn’t because people are dumb. It’s because the system rewards caution without clarity. A thousand well-intended “protections” can turn into a concrete blanket that smothers interoperability, usability, clinician trust, and the app ecosystem that’s supposed to make EHRs betternot just bigger.

1) Build a Committee That Can Outlive the Project

The fastest way to slow down

Innovation hates one thing more than a buggy API: an endless approval chain. If you want to destroy health IT innovation, require every decision to be approved by a steering committee, a subcommittee, and a “rapid response” committee that meets quarterly.

Bonus points if the people closest to clinical workflows are outnumbered 10-to-1 by people who say “synergy” and “stakeholder alignment” with a straight face.

What it breaks

Small experiments die early. Product teams stop proposing improvements because they know “yes” takes four months and “no” takes four minutes. You get conservative designs, safe choices, and a roadmap that reads like an apology.

Do this instead

Use a lightweight governance model: clear decision owners, written criteria, and time-boxed approvals. Committees can advisebut a named owner must decide.

2) Treat Clinicians Like “End Users,” Not Co-Designers

If your goal is to break innovation, wait until go-live week to ask clinicians what they need. Then act surprised that the workflow is slower, the alerts are noisy, and everyone is charting like they’re defusing a bomb.

Health IT isn’t consumer software where “engagement” is the win. In clinical care, usability affects safety, efficiency, and burnout. When the EHR feels like it’s fighting the clinician, innovation gets blamedeven if the idea was good.

How this shows up

• Decision support that fires too often (or for the wrong patients).
• Documentation tools that add clicks without saving time.
• “Optimization” projects led by people who haven’t seen a clinic schedule.

Do this instead

Make clinicians co-owners. Prototype fast, observe real workflows, test changes with patient-safety guardrails, and measure time savednot just features shipped.

3) Confuse Compliance With Progress (a Classic)

To destroy health IT innovation, turn compliance into a performance. Create checklists so long they require their own software. Then declare victory when the boxes are checkedregardless of whether anything improved for patients or staff.

Compliance matters. Privacy matters. Security matters. But “compliance theater” is when teams spend all their energy proving they are safe instead of becoming safeand then they’re too exhausted to innovate.

Do this instead

Build compliance into the product lifecycle: threat modeling early, privacy-by-design, and continuous risk assessment. Reduce paperwork. Increase real controls.

4) Call Data Blocking “Security” and Keep Everything Siloed

There’s a difference between protecting health data and imprisoning it. If you want to kill innovation, conflate “interoperability” with “risk” and treat every data request as suspicious by default.

Here’s what happens: patients can’t easily access or share their records, developers can’t build useful apps, and care teams waste time chasing information that already exists. Then everyone wonders why “digital transformation” feels like fax machines with extra steps.

Where this is especially toxic

• Blocking APIs because “what if someone uses the data?” (Yes, that’s the point.)
• Making third-party integrations impossible unless the vendor is on a short approved list.
• Turning patient access into a slow, manual “records request” workflow.

Do this instead

Use modern interoperability standards (like FHIR-based APIs where appropriate), enforce strong authentication and authorization, log access, and maintain transparent policies that support patients and care coordination.

5) Buy a Monolith, Then Customize It Until Updates Become Mythology

Want to destroy health IT innovation without even trying? Invest in a massive enterprise system and customize everythingtemplates, order sets, workflows, buttons, colors, the laws of physics. Then, when the vendor releases upgrades, discover that your customizations have turned each update into a multi-year archeological expedition.

Customization feels like control. In reality, it often creates technical debt and locks you into a “forever build” that can’t adapt quickly to new regulations, new clinical programs, or new patient-access expectations.

Do this instead

Standardize where you can. Customize where you must. Treat configuration like code: version it, test it, and minimize it.

6) Treat APIs Like a Threat, Not a Capability

Health IT innovation thrives when systems can connect. If you want to crush it, make APIs difficult, expensive, or intentionally limited. Create a labyrinth of contracts, approvals, and “integration fees” so high that only giants can participate. Congratulationsyou just deleted your future app ecosystem.

Patient access APIs, payer-provider data exchange, and modern interoperability frameworks are meant to move the industry away from “data trapped in portals.” When APIs are treated as grudging obligations, innovation becomes a compliance chore instead of a platform advantage.

Do this instead

Design APIs as products: stable documentation, predictable versioning, sensible rate limits, good developer support, and clear security requirements.

7) Underfund Cybersecurity Until a Crisis Becomes Your Roadmap

If innovation is a garden, cybersecurity is the fence. No fence means you spend all your time chasing raccoons instead of growing anything.

Underfunding security doesn’t just increase risk; it also slows innovation. After a cyber incident, everything becomes frozen: integrations pause, vendors get blocked, projects get delayed, and leadership suddenly discovers the phrase “risk appetite.”

Do this instead

Fund baseline controls, incident response, and continuous monitoring. Make security a product partnernot a last-minute gate.

8) Make Documentation the Product (Instead of Care)

Nothing crushes goodwill like technology that “helps” by adding forms. If you want to destroy health IT innovation, measure success by how thoroughly the system captures data for billing and audits, even if the clinician’s day becomes a clicking marathon.

When health IT is perceived as a billing machine with a stethoscope sticker, adoption falls. Clinicians work around the system. Patients get slower care. And any new digital health tool is treated like a new way to waste time.

Do this instead

Reduce documentation burden. Use smart defaults, team-based workflows, automation for administrative tasks, and tools that genuinely save minutesnot add them.

9) Demand Enterprise Perfection on Day One

Innovation dies when pilots are forced to behave like mature programs. If you want to destroy progress, require a new tool to integrate with every system, satisfy every department, and handle every edge case before it can be tested with a small team.

This creates a weird paradox: you need real-world usage to learn what to build, but you require a fully built product before you allow real-world usage. Many good ideas quietly disappear right here.

Do this instead

Start narrow. Pick one clinical workflow, one unit, or one population. Define safety criteria and rollback plans. Learn fast, then scale intentionally.

10) Measure Success With Vanity Metrics

To destroy health IT innovation, track numbers that look impressive but mean nothing. For example: “We launched 37 features.” “We held 19 training sessions.” “We sent 12 newsletters about the new portal.”

Meanwhile, clinicians still hate the alerting system, patients still can’t find lab trends, and your interoperability strategy is basically “good luck.”

Do this instead

Measure outcomes: time saved per visit, reduction in duplicate tests, faster transitions of care, patient comprehension, safety event trends, and clinician well-being indicators.

11) Misread Digital Health Guardrails and Freeze Everything

Digital health products live in a risk-based world: some functions are low risk (wellness, administrative support), others demand stronger evidence and oversight (diagnosis, treatment decisions, high-impact clinical decision support). If you want to kill innovation, treat all digital health tools as equally risky and block them preemptively.

This creates a “no because” culture where teams can’t adopt helpful toolseven when the guardrails are clear and the use case is reasonable.

Do this instead

Use a tiered review process: match scrutiny to risk. Create fast lanes for low-risk tools and structured pathways for higher-risk clinical functions.

How to Not Destroy Health IT Innovation (A Practical Reset)

• Design for interoperability: standards-based exchange, clear API strategies, and patient access as a default capability.
• Co-design with clinicians: usability testing in real workflows, with safety and burnout metrics in view.
• Build security early: privacy-by-design, strong access controls, and continuous risk management.
• Reduce burden: automate administrative tasks; measure time saved, not clicks added.
• Scale intelligently: pilots with guardrails, then expansion driven by evidence and outcomes.

Field Notes: of “Yep, That’s How Innovation Dies” Moments

Here’s what “destroying health IT innovation” looks like in the wildthose scenes teams recognize instantly, even if nobody admits they’re happening.

Monday: The project kickoff starts with big dreams: “We’re going to modernize care with a patient-centered platform.” Thirty minutes later, the dream is renamed “Phase 0 Discovery Alignment,” and your first deliverable is… a slide deck about future slide decks. By lunch, you have three workstreams: Governance, Governance Support, and Governance Enablement. The product team quietly Googles “jobs outside healthcare.”

Tuesday: A clinician champion asks a simple question: “Can this tool reduce after-hours charting?” The room goes silent, because the success metric is actually “documentation completeness for billing.” Someone suggests adding more required fields “just to be safe.” The clinician smiles politely, then never attends another meeting again. Adoption drops, and leadership later calls it “change resistance.”

Wednesday: The interoperability conversation happens. The app team proposes a FHIR-based integration so patients can use a modern experience. Someone says, “APIs are a security risk,” even though the organization already has dozens of external connectionsjust less visible, less standardized, and less controlled. The proposed solution becomes: “Let’s build a portal widget that displays a PDF.” Somewhere, a developer sheds a single tear into their coffee.

Thursday: A security review occursafter the vendor contract is signed and the build is nearly done. The security team finds issues that are solvable but expensive to fix late. The result isn’t stronger security; it’s a launch delay, tense meetings, and a new rule that all innovation requests must be submitted 120 days in advance with a notarized letter from the moon. Nobody is safer, but everyone is slower.

Friday: The pilot is ready. It’s small, controlled, and designed to learn quickly. Unfortunately, someone insists it must support every department, every role, and every edge case “so we don’t redo work.” The pilot turns into a mini-enterprise implementation. Six months later, the tool is still “nearly ready,” the original clinical need has changed, and the team celebrates a milestone: completing the requirements spreadsheet. Innovation is officially replaced by documentation about innovation.

Conclusion

Health IT innovation doesn’t usually get destroyed by one dramatic decision. It gets crushed by a thousand tiny choices: delaying clinical input, treating interoperability like a nuisance, confusing compliance with outcomes, and letting fear outrank learning. The good news is that the same system that can smother innovation can also support itwhen you build platforms (not silos), prioritize usability and patient safety, and create governance that enables speed responsibly.

Or, if you truly want to destroy innovation, you can always schedule one more committee meeting about scheduling committee meetings. That strategy is undefeated.