Direction 1 — patient identities in (Fabric → Heidi). A scheduled job creating and maintaining patient profiles via your Patient Profiles API: our patient number as ehr_patient_id, name, email, DOB. Open questions: API availability and token issuance on our plan (or which tier), update/upsert support on existing profiles, whether existing historical sessions can be retrospectively linked to a synced profile programmatically, rate limits, and the Patient Profiles roadmap from Labs preview to GA.

Direction 2 — sessions out (Heidi → Fabric). A scheduled pull (or webhook on finalisation, if one exists) retrieving finalised sessions: the clinical note, any additional generated documents, and the raw transcript. Open questions: what the API exposes for session/note/transcript retrieval; filtering by date, clinician, patient and template/document type; whether payloads carry the linked ehr_patient_id and a stable session ID; how regenerated notes are versioned; plain-text fidelity of retrieved notes (our notes end in a key=value block that must survive verbatim); and bulk/rate limits for a one-off historical pass across our whole session archive.

Both directions are read/write against Heidi only — nothing clinical flows anywhere except our own Australian-hosted tenant. We have a data engineering partner ready to build the moment we have API documentation and a token, and we're happy to be a reference customer for this pattern. Can we get a call with someone from your API or platform team, with our partner on the line? The two question lists above are the full agenda.