Enterprise Master Person Index (EMPI) Solutions
Definition:
A solution that utilises algorithms on patient records to identify duplicates, errors in patient demographic information, and create a unique enterprise identifier (EUID) for each patient.
Standards and specifications
General requirements
Cyber security
The software must demonstrate ability to effectively achieve mitigation strategies in line with Essential 8.
Core requirements
Standards for identification
The software must:
- be able to discover and validate Individual Healthcare Identifiers (IHI) via the Healthcare Identifier (HI) Service Business-2-Business web services
- 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
- 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 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 software should:
- support the authoring and consumption of clinical documents in Fast Healthcare Interoperability Resources (FHIR®) formats
- capable of using HL7 FHIR-compliant API when sending clinical information
- should be capable of using HL7 FHIR-compliant API when receiving clinical information.
If the system stores, transmits, retrieves, prints, processes or displays medical imaging, it must:
- support the DICOM standard.
Standards for terminology, code sets and classifications
The system must:
- support the use of Medicare Benefits Schedule (MBS) item numbers as defined on MBS online or the DVA schedule on the DVA website.
The system should:
- support person and provider identification in healthcare National Best Practice Data Set
- support the National Clinical Terminology Service (NCTS)
- support the capture of information to support Australian PBS regulatory requirements
- support the use of content from the National Health Services Directory.
Other Standards
International
The system should:
- Content will be updated following consultation feedback
National
The system must:
- AS 2828.2:2019 Health records, Part 2: Digitised health records
- 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 ISO 27269:2022 Health informatics – International patient summary.
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 must 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 discovery 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).
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 system must:
- conform with the HIPS conformance profile V1.
eReferral
The software should:
- have the ability to send and receive ADHA conformant eReferrals.
Discharge Summaries
The software should:
- have the ability to send and receive an ADHA conformance Discharge Summary.
Provider Connect
The software should:
- conform with the Provider Connect Australia service.
State and territory requirements
The following state and territory requirements must be upheld based on location.
State | Theme | Link |
---|---|---|
ACT | Privacy | Health Records (Privacy and Access) Act 1997 (ACT) |
Territory Records Act 2002 (ACT) | ||
Information Privacy Act 2014 | Acts | ||
NSW | Privacy | NSW Privacy Laws |
Requirements for consent | ||
NT | Privacy | Refer to federal legislation for privacy |
QLD | Privacy | Privacy legislation in Queensland |
Informed Consent | ||
SA | Privacy | Refer to federal legislation for privacy |
TAS | Privacy | Refer to federal legislation for privacy |
VIC | Privacy | Privacy and Data Protection Act 2014 |
WA | Privacy | Refer to federal legislation for privacy |
Consent to treatment policy |
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.