Most hospitals should approach clinical AI as a set of build, buy and integration decisions, not a single choice between owning everything and outsourcing everything. Local workflow knowledge can justify internal development, while evidence maintenance, infrastructure and specialist capabilities may be more practical to obtain externally. The right boundary depends on the task and the organisation's ability to support it after launch.
The current market already offers different kinds of external relationships. OpenEvidence and Johns Hopkins Medicine announced a clinical and educational collaboration on 13 October 2026. Doctolib's May 2026 acquisition of Medicus concerns a core UK GP platform rather than a generic hospital AI component. These examples show why the product category must be clear before comparing procurement options. Johns Hopkins Medicine and Doctolib's Medicus announcement.
Begin with the work, not the platform
A hospital seeking better access to local guidelines has a different problem from one trying to automate referral coordination. The first may require authoritative documents, reliable retrieval and a clear ownership process for updates. The second additionally involves patient context, system permissions, destinations, confirmation and recovery when an action fails.
A fictional hospital might initially describe both needs as a clinical AI assistant. Separating them could reveal that its own team can maintain a local policy interface while using an external evidence service for broader questions and established clinical systems for consequential actions.
The value of this decomposition is not technical elegance. It makes the operating responsibilities visible. A product that answers questions well should not quietly inherit responsibility for executing a workflow that has not been assessed.
What an internal build can genuinely offer
An internal team may understand local terminology, pathways, information ownership and clinical working patterns. It can adapt an interface around a particular service rather than waiting for a vendor's general roadmap. It may also have direct access to the staff who can explain why an apparently simple process contains exceptions.
However, proximity does not guarantee capability. The team still needs a maintained source set, reliable engineering, security arrangements and a process for evaluating changes. A successful demonstration built by one enthusiastic clinician or developer is not the same as a supported service with continuity when that person leaves.
A proposed internal business case should therefore name the service owner, technical maintainer, clinical reviewer and support arrangements. It should explain how documents are approved, how outdated material is withdrawn and what happens when the underlying model changes.
What buying can remove, and what it cannot
An external supplier may provide a maintained product, support, content relationships and implementation experience that would be expensive to reproduce. The hospital can then concentrate on selecting an appropriate use case and assessing the deployment rather than building every component.
Buying does not remove the need to understand the product. Its evidence may concern a different population, interface or clinical task. A supplier's general assurance statement may not cover the hospital's proposed configuration or connected systems.
The NHS clinical risk-management standards, checked on 15 October 2026, distinguish manufacturer responsibilities under DCB0129 from deploying-organisation responsibilities under DCB0160 in their applicable English NHS context. Neither internal development nor external procurement is a route around the relevant safety work.
Compare complete operating models
A useful comparison should examine the full lifecycle rather than the first-year purchase price. For an internal build, costs include engineering, clinical review, infrastructure, content rights, support, change testing and staff continuity. For an external product, include implementation, local assurance, integrations, training, ongoing review and eventual migration.
The following is an editorial decision framework, not a universal procurement standard.
| Question | Internal build | External product | Hybrid approach |
|---|---|---|---|
| Who maintains local content? | The hospital must assign and resource ownership | Clarify what the supplier accepts and updates | Local owners maintain approved material within an agreed interface |
| Who handles product changes? | Internal team controls and tests releases | Supplier notification and local acceptance need agreement | Dependencies on both sides require coordinated review |
| Who supports clinical users? | Internal service arrangements are essential | Contracted support still needs a local escalation route | Users need one clear route despite several components |
| How can the service be replaced? | Preserve documentation and staff knowledge | Establish export and exit arrangements | Keep interfaces and responsibilities understandable |
The best choice is the one the organisation can operate responsibly, not necessarily the one with the lowest initial invoice.
Hybrid systems need explicit boundaries
A hospital might retain its own local-policy repository while licensing a general evidence service and using an EHR's authorised workflow functions. That can preserve flexibility, but it introduces boundaries at which information, permissions and responsibility must be reconciled.
HL7 CDS Hooks, checked on 15 October 2026, illustrates a technical approach to invoking decision-support services within clinical workflows. Such standards can help systems communicate. They do not establish that a particular recommendation is clinically appropriate or that every product supports the same integration.
The proposed architecture should show which component retrieves evidence, which supplies patient context, which prepares an action and which authorises execution. It should also show what happens when a component is unavailable. A silent switch to a less-supported mode is not simply a technical convenience.
Evidence ownership matters as much as software ownership
An internally developed tool may feel more trustworthy because its developers work in the hospital. An external product may feel more trustworthy because it has a prominent brand. Neither feeling substitutes for evaluation of the actual workflow.
A staged assessment should examine representative tasks, important failure modes, user interaction and operational consequences. DECIDE-AI, published in 2022, provides reporting guidance for early live clinical evaluation, including human factors. It should inform the evidence conversation without being mistaken for a certificate or a complete authorisation process.
The organisation should also identify who can pause the service, investigate concerns and approve reinstatement. Those decisions become harder when internal teams assume the vendor owns them and the vendor assumes the hospital does.
Do not build what the organisation cannot maintain
A narrow local tool can be more defensible than an ambitious all-purpose assistant. It may solve a specific information-access problem with a manageable source set and a clear owner. Conversely, a broad system requiring continuous clinical content maintenance and extensive integrations may exceed the organisation's practical capacity.
This does not mean innovation should be restricted to large suppliers. It means the development plan should include the unglamorous work that begins after the demonstration: corrections, access reviews, user support, source updates and contingency testing.
The same scrutiny belongs in an external contract. A supplier should explain what is included, what the hospital must provide and which changes require further work. Vendor funding or a prestigious partnership cannot fill those gaps automatically.
Verdict by organisational need
This article is published by iatroX and includes its reference, education and advisory roles in the wider discussion. Its offering, as described on 15 October 2026, is not a replacement hospital EHR or a claimed ready-made orchestration platform. Insights by iatroX supports clinical safety and readiness work, which remains distinct from certification or the hospital's own deployment decision.
For a tightly defined local workflow with a capable maintenance team, internal development may be reasonable. For a broad, continuously maintained clinical capability, buying may reduce duplicated work. Where local context and external expertise are both important, a hybrid can be attractive, provided the boundaries are explicit.
The question is not whether hospitals should become software companies. It is which responsibilities they can discharge well, which they should contract for and how they will ensure that nothing important falls between the two.
Frequently asked questions
Does building clinical AI internally avoid regulatory and safety requirements?
No. Requirements depend on the product function, intended purpose and deployment, not simply whether the developer is a hospital or an external company.
Is a hybrid approach automatically cheaper?
No. It can combine useful capabilities, but integration, coordination and maintenance costs must be included in the comparison.
What should a hospital decide before starting a pilot?
Define the exact task, users, information flows, operating boundaries, evidence needed and the people responsible for maintenance, escalation and stopping use.