Integrations and source ownership

• EHR extract or clinical data warehouse. Deliver deidentified observation-level facts with a stable source reference. Record each capture as a source snapshot with its source system, coverage window, record count and source hash. Identifiable data stays in the source.

• Deidentification and consent process. Deidentify data and establish its consent basis before it reaches the app. Agree the consent basis wording recorded on each fact and cohort.

• Identity provider. Map staff identities to Users and People, with their organization. Removing provider access must also remove the corresponding app access.

• Document storage. Keep evidence files as attachments or link them through the external reference on each evidence document.

• Reporting destination. Where published rates go on to an external quality program, portal or business intelligence tool, record the receipt ID, source, date and evidence on the publication run’s step. A local status change does not replace the destination’s acknowledgement.

Each connection needs an agreed source of truth, a versioned source mapping, a stable record identifier and a retry policy. Keep credentials in the approved secret store and grant the smallest permitted scope. A repeated delivery must not create a second fact, run or result; use the source reference and operation key to detect it. Queue rejected records with the original identifier and a visible reason.

Reconcile each snapshot’s record count with the facts accepted, rejected and still pending. Rehearse a source timeout, a duplicate delivery, a changed mapping and a revoked credential before enabling schedules. Availability depends on each provider’s API, commercial access and configuration.

Use the implementation plan to agree integration acceptance criteria.