Problem before technology
Write the problem down with a measurement. Judge everything against it.
Home / Insights
Insights
Thinking we are willing to put in writing.
Perspectives on healthcare architecture, interoperability, identity, care models and governance, drawn from more than a decade of work across provider, payer, program and product environments. No vendor pitches, and no claims we would not defend in a design review.
Start with the problem, not the technology
The most expensive decisions in healthcare IT are made before the first requirement is written.
Enterprise-first, not project-first
Point solutions are individually rational and collectively ruinous. Enterprise architecture is how an organization stops paying for the same integration five times.
Transport trust is not actor trust
Certificates prove who is on the wire. They do not prove who is allowed to ask, or why. What trusted exchange frameworks still leave to governance.
Delegated access is a design problem
Caregivers are not patients with someone else's login. Designing for them means designing identity, consent and audit as first-class features.
Interoperability deadlines are architecture deadlines
Compliance projects that are run as compliance projects produce a checkbox. Run as architecture, they produce a data-exchange foundation the organization will use for a decade.
Payment models are requirements
Care-management platforms fail when they are designed from the clinical workflow forward and the billing rules backward. Design from both at once.
Measure governance by review burden, not technical difficulty
Architecture review boards fail in two ways: they become bottlenecks, or they become rubber stamps. The fix is to classify work by how much deliberation a decision needs.
Lift-and-shift is a decision, not a default
Cloud migration advice tends to come in two flavors: always refactor, or just move it. Both are wrong often enough that the choice deserves a real analysis.
Themes
What runs through all of it.
Enterprise before project
Every project is evaluated for what it leaves behind for the next one.
Standards before custom
Open standards outlive projects, vendors and staff. Custom needs a documented reason.
Rules are requirements
Regulations and payment models are sources of architecture, not obstacles to it.
Trust is designed, not asserted
Identity, consent and audit are features. Attestation is where governance begins, not ends.
Decisions, written down
An organization that can read its own architecture does not depend on any one person, including us.
Next step
Have a problem these perspectives speak to?
We would rather discuss your situation than publish another essay. Tell us what you are working through.