Skip to main content

Digital Front Door Service

This content is draft for consultation. 

 

Definition:

A secure, single-access, user-friendly platform that combines healthcare data, services and information into one place. It is designed to improve the clinician and patient experience, making it easier for clinicians to access health data and consumers to access digital health services.

Standards and specifications

General requirements

Cyber security

The software must demonstrate ability to effectively achieve mitigation strategies in line with ‘Essential 8’.

Privacy

Data collected about an individual by medical software is likely to constitute health information. Due to the sensitive nature of this information, it generally has a higher degree of privacy protection than other personal information, under relevant federal, state and territory legislations.  

The software must demonstrate adherence to relevant federal, state or territory privacy legislation for example, the Privacy Act 1988 (Federal) or Health Records and Information Privacy Act 2002 (NSW).

The applicable federal legislation is the Privacy Act 1988.

Details of the relevant state and territory legislations are contained under the State and territory requirements section below.

Core requirements

Standards for identification

The system must support:

  • the use of Healthcare Identifiers in accordance with the Healthcare Identifiers Act 2010  
  • data capture and storage of unique device identification of medical devices as defined within AS ISO/IEC 15459.4:2023 Information technology — Automatic identification and data capture techniques — Unique identification, Part 4: Individual products and product packages.  

The system should:

  • be able to discover and validate Individual Healthcare Identifiers (IHI) via the Healthcare Identifier (HI) Service Business-2-Business web services
  • utilise Individual Healthcare Identifiers (IHIs) to integrate and link records into the local patient record
  • support adherence to Patient Identification best practices as outlined by the Australia Commission on Safety and Quality in Health Care.

Australian Core Data for Interoperability (AUCDI)

The system should support the use of AUCDI Release 1.

Note: The focus of the AUCDI Release 1 is the representation of the clinical content necessary for each of the data groups identified within the Release 1 scope.

Development is continuing to enhance AUCDI.

Standards for data sharing

The system should:

  • support the consumption of clinical documents in Fast Healthcare Interoperability Resources (FHIR®) formats.
  • capable of using HL7 FHIR-compliant API when sending clinical information.
  • be capable of using HL7 FHIR-compliant API when receiving clinical information.

Standards for terminology, code sets and classifications  

The system must:

  • support the use of MBS item numbers as defined on MBS online or the DVA schedule on support Australian Medicines Terminology (AMT)
  • support the inclusion of medicines listed on the Australian Register of Therapeutic Goods (ARTG).

The system should support:

  • person and provider identification in healthcare National Best Practice Data Set.
  • the capture of information to support Australian PBS regulatory requirements
  • the use of content from the National Health Services Directory.

National Safety and Quality Health Service (NSQHS) Standards

Implementation of NSQHS is mandated in all hospitals, day procedure services and public dental services across Australia.

The system must:  

  • support adherence to best practices related to Informed Consent  
  • support adherence to all relevant National Safety and Quality Health Service Standards in accordance with the intended scope of the system being procured. These may include, but not limited to the following standards:  
    • Partnering with Consumers Standard
    • Communicating for Safety Standard
    • Comprehensive Care Standard
    • Blood Management Standard
    • Medication Safety Standard
    • Clinical Governance Standard.
  • support adherence to all relevant Clinical Care Standards.

Other Standards

International

Where appropriate, the system should support:

  • ISO13485: Quality Management for Medical devices
  • ISO 21090:2011 Health informatics — Harmonized data types for information interchange.

National

The system must comply with:

  • AS2828.2: Digitised health records where digitisation of paper records is required.  
  • SA TS 90007.1:2014 Consumer entered information, Part 1: Logical content specification
  • SA TS 90007.2:2014 Consumer entered information, Part 2: CDA implementation guide
  • AS ISO 18308:2022 Health informatics — Requirements for an electronic health record architecture
  • ATS ISO 14265-2013 Health informatics – Classification of purposes for processing personal health information
  • AS 5552-2013 E-health secure message delivery.

Connections to National Systems

Healthcare Identifiers Service (HI Service)

If the software is expected to deal with healthcare identifiers (e.g. in a hospital environment) then it should either:

  • be able to discover and validate Individual Healthcare Identifiers (IHI) via the Healthcare Identifier (HI) Service, or

Where the enterprise utilises an enterprise-wide system for discover and validation of Individual Healthcare Identifiers (IHI) the software should:  

  • be able to manage and interface with this middleware in order to enable discovery and validation of Individual Healthcare Identifiers (IHI).

My Health Record  

The software must:  

  • be able to respect patient instruction not to upload at a patient and document level when contributing clinical information to the My Health Record system
  • be able to access record information from the My Health Record as required
  • support patient instruction not to upload.

Note: If the system is not connecting to My Health Record, then these can be removed.  

Registries e.g. Australian Immunisation Register (AIR), Australian Breast Device Registry (ABDR)

The software should:

  • connect to the Australian Immunisation Register (AIR).

The software should:

  • connect to the Australian Register of Therapeutic Goods (ARTG).

API Gateway or Government Provider Management System (GPMS)

For aged care services, the software should:

  • be capable of sharing relevant data to the GPMS.

National Authentication Service for Health (NASH)

If the system is connecting to My Health Record, the software must:

Conformance

HI service

The software should:

  • have production access to the Health Identifiers Service.

Healthcare Information Provider Services (HIPS)

If the system connects to the Healthcare Information Provider Service (HIPS) middleware product, the software must:

  • conform to the HIPS conformance profile V1.

My Health Record

The software should:

  • conform with the My Health Record Conformance Assessment Scheme.

Provider Connect

The software should:

  • conform to the Provider Connect Australia service.

State and territory requirements

The following state and territory requirements must be upheld based on location.

Date last updated: 20 January 2025