Healthcare AI is becoming an ecosystem, not a single assistant. Documentation, evidence, imaging, monitoring, referral, medication and patient-facing tools will coexist. The governance model must therefore scale beyond approving one ambient scribe.
Approval should attach to an intended purpose
A general-purpose model can perform many tasks, but an organisation evaluates a defined use. The approval should specify who may use the application, for which patients and workflow, what data it requires, what outputs it can produce and where human approval occurs.
“AI tool approved” is too broad. A documentation application approved to return a draft clinic letter should not automatically gain access to restricted notes or permission to place orders.
Give every application a passport
A CareStrand App Passport is a structured description of the application boundary. It can include:
- supplier, application, model and model version;
- intended purpose and permitted users;
- required and prohibited data;
- read, launch, draft, suggestion and transaction permissions;
- hosting, retention and training rules;
- evidence, regulatory position and known limitations;
- human approval, monitoring, rollback and incident process.
Permissions should be progressive
A practical ladder starts with no patient data, then context launch, scoped read, draft output, suggested action and finally an explicitly approved transaction. Most applications do not need the highest tier.
Progressive permissions create a safer adoption route. An organisation can demonstrate value through launch and drafting before considering source-system write-back.
Model changes are product changes
If the model, prompt, retrieval pipeline or permission changes materially, the previous approval evidence should not remain silently valid. The passport version should change, its integrity evidence should be invalidated and the affected workflow should be retested.
Healthcare organisations need to know not only which application produced an output, but which version and approval boundary were in force.
The platform and the application have different responsibilities
CareStrand can assure identity, context assembly, permissions, provenance, workflow and audit. The application supplier remains responsible for its intended purpose, performance, limitations and product evidence. The deploying organisation remains responsible for the local pathway, users, configuration and clinical-safety deployment work.
A shared gateway should make these responsibilities clearer, not blur them.
Human review must be meaningful
“Human in the loop” is not sufficient if the reviewer cannot inspect sources, understand what changed or correct the output before it affects care. The interface should place evidence, uncertainty and conflicting information beside the approval decision.
High-volume review also creates automation bias. Monitoring should include edit and rejection rates, unsupported assertions, missed information and whether the workflow encourages rubber-stamping.
Design for revocation from the start
An approved application may need to be suspended because of a model change, security issue, poor performance or contractual change. CareStrand should be able to stop new context release immediately while retaining the passport, historical outputs and audit evidence.
The commercial opportunity
A governed application gateway can reduce duplicated integration and assurance work. Specialist suppliers gain a consistent connection pattern; healthcare organisations retain local control; clinicians receive tools inside a stable patient and workflow context.
The moat is not an app marketplace by itself. It is the combination of reusable integration, policy, evidence and safe action across many heterogeneous healthcare environments.
The product opportunity is the workflow and governance layer—not another disconnected record viewer.
CareStrand is currently a synthetic demonstrator. The ideas described here require organisation-specific integration, assurance and evaluation before production use.