Skip to main content

Electronic Medical Record (eMR)

This content is draft for consultation. 



A system utilised day to day by clinicians and staff to gather, manage and consult patient information and data to inform and record patient care delivery in real time. 

These systems may also be referred to as Electronic Patient Record (EPR) or Digital Health Record (DHR).

National standards and specifications 

General requirements

Cyber security 

The software must demonstrate adherence to the ‘Essential 8’ cyber security principles.  


Data collected about an individual by medical software is likely to constitute health information (which is sensitive information, a category of personal information that generally has a higher degree of privacy protection than other personal information) under relevant federal, state and territory privacy legislation. (e.g. Privacy Act 1988 (Cth), Health Records and Information Privacy Act 2002 (NSW) etc).

The software must demonstrate adherence to relevant Federal, State or Territory privacy legislation. 

Applicable Federal legislation is the Privacy Act 1988 (cth). Details of the relevant State and Territory based legislation are contained in the State requirements section.

Core requirements 

Standards for identification

The software must:  

  • support the use of Healthcare Identifiers in accordance with the Healthcare Identifiers Act 2010
  • integrate Individual Healthcare Identifiers (IHIs) into the local patient record
  • where the EMR stores local directory for Healthcare Providers allow for: 
    • the storing of Healthcare Provider Identifier-Organisation (HPI-O) in the local system associated with the locally stored healthcare provider organisation details and 
    • the storing of healthcare provider identifier-individual (HPI-I) in the local system associated with the locally stored healthcare provider individuals’ details.
  • support 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 
  • 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 software should 

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. These data groups include Adverse reaction risk summary (allergies and intolerances), Problem/Diagnosis summary, Procedure completed event, Vaccination administration event (immunisations), Vital signs, measurements and other biomarkers for chronic disease and preventative health with an initial scope of cardiovascular risk calculation and diabetes care, Medication use statement, Sex and gender, and Encounter information necessary to provide clinical context. Development is continuing to enhance AUCDI, at which time the detail in this section will be updated.

Standards for data sharing

The software should:  

  • support the authoring and consumption of clinical documents in Fast Healthcare Interoperability Resources (FHIR®) formats. 
  • support HL7 Fast Healthcare Interoperability Resources (FHIR®)-compliant API as the base standard communication process
  • support an API compliant with HL7 version 2.4.1 and the ORM specification as a minimum

Standards for terminology, code sets and classifications  

Where appropriate the system must

  • support Systematised Nomenclature of Medicine-Clinical Terms AU (SNOMED CT-AU) for the collection and storage of:
    • Procedures
    • Events
    • Observations (including Nursing)
    • Body structure

Further use cases should be considered based on individual organisational requirements.

  • support the use of Australian Medicines Terminology (AMT) for the storage of patients current medicines. 
  • where system will also be used to manage prescriptions, AMT should also be used.  
  • support Logical Observation Identifiers Names and Codes (LOINC®) 
  • support Data Set Specifications including but not limited to National Minimum Data Sets (NMDS), as defined within Australian Institute of Health and Welfare Metadata Online Registry (Meteor).

The system should:

  • support person and provider identification in healthcare National Best Practice Data Set.

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 National Standards 

The system must:  

  • support compliance to AS2828.2: Digitised health records where digitisation of paper records is required.

Connections to National Systems

HI Service: 

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

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

  • 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 
  • be able to upload an Event Summary to the My Health Record system, if required 
  • support patient instruction not to upload 

Where it is a source system for capture, it must also: 

  • be able to upload a Discharge summary to the My Health Record system 
  • be able to upload Diagnostic Imaging reports to the My Health Record 
  • be able to upload Discharge Dispense Medication to the My Health Record  


The software must:  

  • have production access to the My Health Record 
  • have production access to the Health Identifiers Service 

State-based requirements  

The following state-based requirements should be considered based on your location. 

All requirements must be supported based on location. 

Contact us 

This content is draft for consultation. To learn more about the Guidelines, the phased publication approach, or if you are interested in being part of future reference groups, please contact us via the form below.