RESOURCES · INTEROPERABILITY
FHIR R5 Integration for Medical Scribes: A Practical Guide
What FHIR and SMART on FHIR actually mean, how clinical note integration can work, and what MedTalk AI currently confirms about its own support.
FHIR and SMART on FHIR, in plain words
FHIR (Fast Healthcare Interoperability Resources) is a widely adopted technical standard for exchanging healthcare data between systems, an Electronic Health Record (EHR), a lab system, and a clinical app, for example, using a common set of data structures ("resources") such as Patient, Encounter, and DocumentReference. FHIR R5 is the current major version of that standard.
SMART on FHIR is a separate, complementary standard for authorisation: it defines how an external application can launch securely from inside an EHR (or be authorised to call its FHIR API directly), with the right patient, encounter, and user context passed through automatically, rather than the clinician re-entering that context by hand.
Together, they are what let a third-party clinical app, such as an AI scribe, connect to a hospital or clinic's EHR in a standardised, auditable way instead of a one-off custom integration.
How clinical note integration can work, in general
This section describes how a FHIR-based integration between an AI scribe and an EHR can work in general. It is educational background, not a description of any specific vendor's current capability.
- Launch and context: the scribe is launched from within the EHR (or authorised separately) via SMART on FHIR, receiving the current patient and encounter identifiers.
- Read context (optional): with permission, the scribe can query relevant FHIR resources, such as problem lists, medications, or allergies, to inform the note it generates.
- Write-back: once a clinician finalises a note, it can be written back into the EHR as a structured FHIR resource, commonly a DocumentReference or a Composition, rather than pasted in as unstructured text.
- Terminology: where the EHR expects coded data (for example, SNOMED CT or LOINC codes) rather than free text, the integration needs to map generated content to the correct codes.
- Audit: every read and write should be logged, consistent with the EHR's own audit and access-control requirements.
The depth of a real integration varies a great deal: "FHIR-compatible" can mean anything from a one-off document export to a certified, bidirectional, resource-level integration reviewed by a hospital's IT security team. It is worth asking a vendor which of these they actually mean.
MedTalk AI's confirmed integration support
Kept separate from the general explanation above, this is what MedTalk AI currently confirms in its own product documentation.
- Epic: native FHIR R5 and SMART on FHIR integration, piloted with ACT Health (Canberra Health Services) in an Epic Digital Health Record environment. MedTalk AI is a recognised Epic Vendor Panel Partner. See FHIR Integration and MedTalk × Epic.
- Best Practice Software: a confirmed integration partnership with Australia's largest GP software platform. See Integrations.
- Cerner (Oracle Health), Athena, and Meditech: on Professional and Enterprise plans, MedTalk AI supports structured clinical note export formatted for these systems. This export compatibility is distinct from a confirmed integration partnership; named partner status is only published once contractual and technical status is confirmed. See Integrations.
- Enterprise deployments: custom FHIR-based integrations and HL7 messaging are supported for enterprise customers on a project basis. Contact support@medtalk.co to scope a specific deployment.
What deployment actually requires
A FHIR integration into an existing hospital or clinic EHR is a project, not a toggle. At minimum, expect a hospital IT and clinical governance team to want to confirm:
- Which FHIR version is supported natively, not just "FHIR-compatible" in general terms.
- How SMART on FHIR launch and authorisation is configured for that specific EHR instance.
- Where data is hosted and processed, and whether that meets the organisation's data residency requirements.
- What security review and sign-off process applies before any pilot can begin.
- A realistic timeline: enterprise EHR integrations typically take months, not weeks, and usually proceed through a limited pilot before any wider rollout.
A more detailed walkthrough of the enterprise deployment process, including what a hospital-scale pilot looks like in practice, is covered in Ambient AI for Hospitals.
Contact
Integration enquiries: support@medtalk.co