Digital Health Technology Governance Policy Template for Australian General Practices

What's in this template?

This policy decides whether your practice adopts a digital health technology, what it checks before saying yes, who approves it, what patients are told, how the technology is supported while it runs, and what happens to the data when it is retired. It is built from criterion F10.A of the RACGP Standards for general practices (6th edition), published 26 August 2026, and covers the criterion's four parts: safe and secure use, informed patient consent, a documented process for assessing, costing, implementing and managing technologies, and access to technical experts.

F10 is new. It has no 5th edition equivalent, so there is no existing practice document to adapt. Everything in this template is written against the 6th edition criterion and its published guidance.

One line in that guidance is worth reading twice. The RACGP's "why this is important" text for F10 runs in the usual soft register until it says that adherence to a documented data governance policy addressing the use of digital health technologies is needed to maintain the integrity and security of patient information. Elsewhere the guidance says "could". Here it says "is needed". This document is what answers it.

The template runs to 14 numbered sections and 2 appendices:

1. Purpose: the criterion, the consumer expectation behind F10, and where accreditation currently stands
2. Scope: who it binds, a definition table of what counts as a digital health technology at your practice, and what is deliberately out of scope
3. How this relates to the AI and information security policies: the three-way boundary table, restated below, plus where the Telehealth Policy sits
4. Governance roles and approval authority: the named lead, the approver, and how the role overlaps with F8.B's digital governance role
5. Assessing a technology before adoption: the nine-stage assessment, from clinical safety through to exit
6. Decision, approval and recording: approved, approved with conditions, or declined, and why the declines get recorded too
7. Implementation and change management: pilot, training, testing after vendor updates, telling patients, off-site working
8. Informed patient consent: which technologies need it, what the conversation covers, how it is recorded
9. Managing technologies in use: the register, monitoring signals, the four review questions, and what escalates immediately
10. Technical support and collaboration with technical experts: the third F10.A requirement, which is about planning and optimising, not only fixing
11. Decommissioning and exit: getting the data out before the account closes
12. Roles and responsibilities
13. Related documents
14. Approval and review: version control and a signature block

Appendix A: Register of approved digital health technologies is a fillable landscape table covering the technology and vendor, its purpose, the patient information held and where, whether consent is required, the technical support contact, who approved it and when, and the review dates. One row ships filled in as a worked example.

Appendix B: Pre-adoption assessment record is the fillable evidence behind the documented-process requirement: one row per assessment stage, with the question each stage asks already written in, plus columns for the finding, the evidence held, who assessed it and the date.

Editable placeholder fields

Yellow-highlighted {{ }}Placeholder{{placeholder}} fields for {{ }}Practice name{{practice_name}}, {{ }}ABN{{abn}}, {{ }}Practice address{{practice_address}}, {{ }}Digital health lead{{digital_health_lead}}, {{ }}ICT security responsible{{ict_security_responsible}}, {{ }}Privacy officer{{privacy_officer}}, {{ }}Clinical lead{{clinical_lead}}, {{ }}It provider name{{it_provider_name}}, {{ }}It provider contact{{it_provider_contact}}, {{ }}Remote access arrangement{{remote_access_arrangement}}, {{ }}Approved by{{approved_by}}, {{ }}Effective date{{effective_date}}, {{ }}Next review date{{next_review_date}} and the sign-off dates.

Three documents, three different questions

Practices commonly hold two of these three and assume the set is complete. It is not, and the gap is usually this one.

A worked example makes the split obvious. A practice signs up to a patient portal so patients can view their results. The security policy answers whether the portal has multi-factor authentication and where the data sits. The AI policy answers nothing at all, because no AI is involved. Everything else belongs to this policy: whether anyone assessed the portal for clinical safety before it went live, whether anyone costed the integration and the ongoing licence, whether reception knows what to do when a patient rings about a result they read at 9 pm, whether patients were told, and what happens to the stored results when the practice changes provider next year.

Where a technology uses AI, it sits under both this policy and the AI policy, and goes on both registers. Assess it here for purpose, cost, workflow and support. Assess it there for what happens to the data the model sees, whether the vendor trains on inputs, and how the clinician reviews the output.

The Telehealth Policy is a fourth, narrower document: it governs a single modality in clinical detail, including MBS eligibility rules, patient identification and location, and when a consultation must be converted to face to face. This policy governs the platform behind it: how it was chosen, what it costs, who supports it, and when it is next reviewed.

What RACGP criterion F10.A actually requires

The consumer expectation statement behind F10 reads:

"I expect that digital health technologies provided by this practice are easy to access and use; secure and regularly assessed; and my consent is obtained prior to use."

F10.A: the practice uses digital health technologies safely and securely. The criterion then names three things the practice does:

• facilitates processes for members of the clinical team to obtain informed consent from patients when using digital health technologies
• has a documented process for assessing, costing, implementing and managing digital health technologies, including consideration of their potential impacts on the practice, members of the practice team and patients
• provides members of the practice team with access to and opportunities for collaboration with technical experts for the digital health technologies it uses in the provision of high-quality patient care

What counts as a digital health technology

The RACGP defines the term as digital technologies used to deliver healthcare services remotely, or to enhance in-person care, and so improve accessibility, continuity and efficiency in patient care. Its own examples are telehealth, mobile health apps, patient portals, remote monitoring devices and secure messaging platforms. In practical terms, for an Australian general practice that means secure messaging, electronic prescribing, My Health Record, patient portals, online appointment and digital intake systems, SMS recall and reminder platforms, remote monitoring and wearables, and any new module a vendor switches on inside software you already run. A feature you did not choose is still a technology you are running.

The parts of the guidance that are firmer than "could"

Most of the F10 guidance is written as suggestions. Four items are not, and they are the ones to build against:

• Any proposal for new technology includes a systematic, operational assessment of its impact before implementation. The guidance names workflow changes, team readiness, resource requirements, costings and consumer experience.
• All hardware and software is tested regularly, and after any updates or changes to functionality, to confirm reliability.
• The connection and the equipment have to be good enough for the clinical job: a reliable internet connection capable of supporting multiple concurrent video consultations where the practice does telehealth, and sound and image quality suitable for clinical purposes.
• Off-site working needs real capability: communication to and from the practice, remote access to clinical records, read and write access to the clinical information system, and My Health Record access where applicable.

The consent requirement, read carefully

F10.A says the practice facilitates processes for the clinical team to obtain informed consent. That word matters. The practice does not obtain consent; the clinician does, in the consultation, tailored to the patient. What the practice owes is the supporting structure: a decided position on which technologies need a consent conversation, agreed content for that conversation, a place to record it, and a real alternative to offer when a patient declines. The guidance asks practices to support clinicians to explain how the technology will be used, including its limitations and risks, to inform patients how their information will be collected, used, stored and shared, to tailor the conversation to the patient's digital literacy, and to give guidance on when consent should be revisited, for instance when a different technology is introduced.

Section 8 of the template turns that into a table your clinical team can argue with and then adopt.

The medical device question, without the overclaim

Some software used in clinical care is regulated by the Therapeutic Goods Administration, and plenty of it is not. Software meeting the definition of a medical device under section 41BD of the Therapeutic Goods Act 1989 is regulated unless it has been excluded, and where it is regulated and not exempt it must be included in the Australian Register of Therapeutic Goods before it is supplied in Australia. Two qualifications matter to a practice:

• The ARTG obligation sits with the manufacturer or sponsor supplying the product, not with the practice using it.
• The Therapeutic Goods (Excluded Goods) Determination 2018 carries 15 categories of excluded software, among them electronic health records software, clinical workflow management software, communications software, image storage and transmission software, health facility management software, patient survey software and health alert software systems. Assuming every clinical tool needs an ARTG number is as wrong as assuming none of them do.

What the practice actually does is narrow: ask the vendor to state the product's regulatory status in writing, record the answer on the assessment, capture the ARTG number where there is one, and get advice where the answer is unclear and the product influences clinical decisions. That is stage 5.4 of the template, and it takes one email.

Where accreditation actually stands

Practices are still accredited against the 5th edition. The RACGP has said that transition arrangements under the National General Practice Accreditation Scheme, including timing and requirements, will be communicated by the Australian Commission on Safety and Quality in Health Care, and nothing has been published. F10.A is not assessable today, and no compliance deadline exists. Our 6th edition contents map and migration guide cover the full picture.

The argument for doing it now is not the deadline. It is that the register and the assessment records are the evidence F10.A asks for, and neither can be produced retrospectively with any credibility. A register built the week before a survey lists what you use. A register with two years of dated approvals, reviews and one retirement shows a practice that governs its technology. The first version costs an afternoon; the version that counts costs nothing extra, because it is the same document kept up to date.

How to customise this template

1. Download the Word document and replace every {{ }}Placeholder{{placeholder}}.
2. Name your digital health technology lead in Section 4, and check the F8.B overlap table while you are there. If your ICT security sits with an external provider, F8.B already asks for an internal person with primary responsibility for digital governance. In most practices that person and this lead should be the same one.
3. Cut Section 2.1 down to what you actually run. The table lists nine technology types drawn from the RACGP's examples and the Australian Digital Health Agency's national infrastructure. It is a starting point, not a checklist of things a practice is expected to have.
4. Fill in Appendix A before you circulate the policy. Walk the practice and ask what the clinical team, reception and billing are using, including modules switched on inside existing software. Most practices find at least one thing nobody approved.
5. Run the Section 5 assessment over what is already in use, not only over the next proposal. Record each assessment on the date you actually did it, using Appendix B. Backdating helps nobody.
6. Decide Section 8 with your clinical team before publishing it. The consent table is the practice's own position, not a quotation from the Standards, and a position clinicians did not agree to will not be followed.
7. Set your review dates on the register, and add a review trigger for when the Commission publishes the transition arrangements.

Related templates and tools

• AI Acceptable Use Policy: the AI-specific half of practice technology governance, answering RACGP F11 and the OAIC's guidance on commercially available AI products. A technology that uses AI belongs on both registers.
• Computer and Information Security Policy: the baseline controls every technology sits on top of, and the document that governs the security review at stage 5.3.
• Telehealth Policy: the clinical conduct of telehealth consultations, including MBS eligibility, identification, location and consent at the start of each consultation.
• Privacy Impact Assessment: stage 5.2 of the assessment for any technology that will hold or transmit health information.
• Data Breach Response Plan: where an exposure involving a digital health technology goes, assessed under the Notifiable Data Breaches scheme.
• Data Retention and Destruction Policy: retention obligations survive the retirement of the platform holding the records.
• RACGP Standards 6th edition: what is in it: the contents map of all five standards and which criteria are new.
• RACGP Accreditation Readiness Quiz: a baseline against the 5th edition criteria you are still assessed on today.

Frequently asked questions

Is a digital health technology governance policy required right now?

No. Practices are still accredited against the RACGP Standards for general practices (5th edition), which has no equivalent to F10. The 6th edition was published on 26 August 2026, and transition arrangements under the National General Practice Accreditation Scheme have not been published by the Australian Commission on Safety and Quality in Health Care. No date has been announced. Your accrediting agency will confirm which edition your next assessment runs against.

What is RACGP criterion F10.A?

F10.A is the single criterion in the F10 Digital health technologies criteria set, in the Foundations of general practice standard of the 6th edition. It requires the practice to use digital health technologies safely and securely, and names three things the practice does: facilitate processes for the clinical team to obtain informed consent from patients, hold a documented process for assessing, costing, implementing and managing digital health technologies including their potential impacts, and provide the practice team with access to and opportunities for collaboration with technical experts. It is new, with no 5th edition equivalent.

How is this different from our information security policy?

They answer different questions. The security policy is about protecting the systems the practice already runs: user accounts, passwords and MFA, backups, malware, patching, devices, networks and incident response. This policy is about the decision to run a system in the first place, and everything that follows from it: assessment, costing, approval, patient consent, review and retirement. A practice can be fully compliant with its security policy and still have adopted a patient portal nobody assessed, costed or told patients about.

Does this replace our AI policy?

No, and neither replaces the other. F11 covers artificial intelligence specifically, with obligations the AI Acceptable Use Policy is built around: de-identification, keeping identified patient data out of AI tools unless clinically necessary and authorised, documented clinical oversight of AI output, and clinician accountability for care decisions supported by AI. F10.A covers the full lifecycle of every digital health technology, AI or not. A technology that uses AI is assessed under both and appears on both registers.

What has to go in the technology register?

One row per digital health technology the practice has approved and is running: the technology and vendor, what it is for, what patient information it holds and where that information is stored, whether patient consent is required and at what point, the technical support contact, who approved it and when, and the review dates. Include modules and features a vendor has switched on inside software you already use. Keep retired entries in the register, marked retired with the date, rather than deleting them.

Do we need patient consent for online booking and SMS reminders?

The template's position is that technologies which change how a patient interacts with the practice, without changing the care itself, are handled by informing patients and recording their contact preferences rather than by individual consent, with an opt-out available. Technologies used in the delivery of care to an identified patient, such as telehealth, remote monitoring or a patient-facing app, get a documented consent conversation from the treating clinician. That is a practice position, not a quotation from the Standards, and Section 8 is written so your clinical team can adjust it before it is published.

Does our practice management software need to be on the ARTG?

Probably not, but ask the vendor rather than assuming either way. Software meeting the medical device definition under section 41BD of the Therapeutic Goods Act 1989 is regulated by the TGA unless excluded, and the Therapeutic Goods (Excluded Goods) Determination 2018 excludes 15 categories of software including electronic health records, clinical workflow management, communications, image storage and transmission, and health facility management software. The ARTG obligation also falls on the manufacturer or sponsor, not the practice. The practice's job is to ask for the vendor's written statement of regulatory status, record it, and seek advice where the answer is unclear and the product influences clinical decisions.

What does "access to technical experts" actually mean for a small practice?

Less than it sounds. The guidance says collaboration goes beyond arranging support after implementation: it also means engaging technical experts when planning, implementing and optimising the technology. For a solo or small practice, that is usually a single existing IT support agreement plus a standing quarterly call to review how the systems are performing, along with a support contact recorded against each technology on the register so no one has to ask who to ring. What fails the criterion is a technology in daily use with no named support arrangement at all.