A healthcare organisation can own its information and still struggle to leave the software used to organise it. Export may be technically possible while producing files that lack the structure, relationships or status information needed to continue work elsewhere.
That makes portability a practical sovereignty question. The relevant test is not whether a supplier permits cancellation. It is whether the organisation can retain the records and operational understanding it needs without unacceptable disruption.
This guide applies to clinical AI procurement generally. Tandem's Sovereign Health announcement creates a timely reason to ask about control, but it does not establish Tandem's detailed export terms or a demonstrated migration into another product.
Lock-in can exist in several places at once
The most visible dependency is data. Less visible dependencies include templates, local instructions, specialist configuration, integration settings, staff familiarity and the workflows built around the product.
An organisation might be able to download approved notes but not recover the rules used to assemble a referral. It might retain every generated document while losing a reliable account of which ones were filed or sent.
Commercial terms create another layer: notice periods, minimum commitments, exit support charges and access after termination can affect the feasibility of a move.
The UK government's cloud lock-in guidance distinguishes commercial and technical dependence and recommends balancing portability against value. It does not treat eliminating every dependency as realistic or necessarily desirable.
Define the asset before asking for an export
"All our data" is too broad to test and sometimes too vague to negotiate.
Identify what the organisation needs for continuing care, investigation, records management and operation. Distinguish approved clinical records from temporary working material and supplier-owned software.
A request for continuity information is not automatically an entitlement to the supplier's model weights, source code or proprietary templates. Those rights need to be established rather than inferred from a customer relationship.
The following is an original exit-planning matrix. It describes questions to resolve, not a universal requirement that every category must be retained indefinitely.
| Asset | What a usable handover should establish | A test to perform |
|---|---|---|
| Approved notes and letters | Content, patient association, date and approval status | Compare an exported item with the authorised source record |
| Unfinished drafts | Their status and whether they remain required | Distinguish a current draft from one superseded by manual work |
| Pending actions | Ownership, destination and last confirmed state | Reconstruct what another team still needs to do |
| Relevant audit information | The events needed to investigate material changes | Follow a fictional correction from generation to filing |
| Local templates and instructions | The rights and formats needed to reuse them | Rebuild a representative local document elsewhere |
| Integration configuration | Dependencies, permissions and replacement arrangements | Demonstrate a permitted transfer in a test environment |
| User and role configuration | Which access should continue or end | Check that the new permissions match the intended team |
The matrix is more useful than a statement that the export is available in a familiar file type. A spreadsheet containing identifiers without their relationships may be readable but operationally inadequate.
Open formats help, but they do not guarantee a working move
A common format can reduce dependence on one application. It does not establish that another system interprets the contents correctly.
Dates, units, status labels and links between records still require attention. A receiving system might treat a provisional draft as a final note or lose the relationship between a correction and its earlier version.
HL7's FHIR Provenance resource illustrates how information lineage can be represented. Its presence is not a guarantee that every migration preserves the required clinical meaning or that an exported statement is true.
A good portability test therefore includes both technical loading and interpretation by the people who will use the information. Successful parsing is the beginning of the test, not its endpoint.
A fictional clinic tests the exit before signing
Imagine a specialist clinic considering a documentation service. It supplies a small set of fictional encounters containing an amended note, a draft letter and a task awaiting confirmation.
The supplier produces an export. The clinic's technical team can open every file, but the clinical reviewer cannot distinguish the approved note from its earlier draft. The task list also shows a destination without showing whether the item was sent.
That is a useful discovery before adoption. The response might be a more complete export, a separate status report or an agreement that definitive records and tasks remain in the clinic's existing systems throughout use.
The example does not establish that the supplier must recreate its whole application elsewhere. It identifies the minimum information the customer needs to avoid losing clinical continuity.
Keep the authoritative record identifiable during transition
A migration can create two accessible versions of apparently the same information. The organisation needs to know which is authoritative at each stage.
Choose a cutover arrangement, identify which users can amend each system and establish how late changes will be reconciled. Avoid leaving staff to decide based on whichever version appears most recent on their screen.
The distinction matters particularly when generated drafts are involved. An AI document should not become an approved historical record merely because it survived export.
The continuity article addresses similar status problems during an outage. Planned departure allows more preparation, but the underlying need to distinguish completed and unfinished work remains.
Price the exit in work as well as money
A quoted export fee is only one part of the cost. The organisation may need time for configuration, testing, training, reconciling records and supporting staff through a temporary reduction in familiarity.
Estimate those activities explicitly. Identify the people involved, the assumptions about volume and the circumstances that could extend the transition.
Do not assign a standard number of migration days to every clinic. Moving a narrow drafting tool that files approved outputs into an existing record is a different project from replacing an embedded workflow holding essential task state.
The government guidance recommends considering exit costs and time within the business case. A proportionate healthcare adaptation also considers the consequences for patients and outstanding work, rather than treating departure as a purely commercial transaction.
Deletion and access need their own agreement
Cancellation, loss of login access and deletion are separate events.
Establish the period during which the organisation can retrieve information, the assistance available, the treatment of backups and the process for any material retained for a justified purpose. The agreement should distinguish what is deleted from what is preserved and why.
The ICO's storage-limitation guidance does not prescribe one retention period for all personal information. An exit plan must fit the relevant purposes and obligations rather than demand indiscriminate deletion or indefinite access.
This is an organisational procurement question, not a claim that an individual's data-portability rights automatically provide a complete business-system migration.
Some dependence may be worth accepting
A tightly integrated product can remove substantial work. Rebuilding every capability to avoid relying on it may be more expensive and less dependable.
The useful distinction is between understood dependence and accidental dependence. A clinic can reasonably accept switching costs when the service provides sufficient value and the exit remains manageable.
Record what would change that judgement: repeated failures, an unacceptable processing change, a material price increase or a loss of necessary support. Then revisit whether the organisation's ability to leave has changed as its use expands.
A narrow pilot can become a much deeper operational commitment without another purchasing event. Periodic review should notice that change.
The stronger question for a sovereignty claim
Ask what the customer can independently retain, restrict, replace and recover. A supplier operating its own model may gain freedom from an upstream provider without passing equivalent freedom to its customers.
Those are different layers of control. Neither makes the other unimportant.
A useful exit demonstration shows that approved records remain intelligible, unfinished work remains owned and the next service can operate. That is more meaningful than a download button or a statement that the contract can be cancelled.
Frequently asked questions
Does owning our patient data mean switching AI supplier will be easy?
No. Formats, status information, integrations, configuration and staff processes can create dependencies even when ownership is clear.
Must we avoid every product with proprietary components?
No. Proprietary capabilities can provide substantial value. Assess the rights, costs and practical alternatives associated with the dependence rather than treating openness as a complete purchasing decision.
What is the most useful portability test before procurement?
Use fictional records and unfinished tasks to demonstrate export, interpretation and continuation in an alternative environment. Check clinical meaning and task status as well as whether the files open.
Take a concrete exit question into your next supplier meeting