Medical Imaging and Radiology Information Systems

 

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 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 software stores a 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 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 DICOM standard

•     support the authoring and consumption of clinical documents in Fast Healthcare Interoperability Resources (FHIR®) formats.

Standards for terminology, code sets and classifications  

The system should:

•     support Systematised Nomenclature of Medicine-Clinical Terms AU (SNOMED CT-AU)

•     support Logical Observation Identifiers Names and Codes (LOINC®)

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

National

The software should:

• connect to the Healthcare Information Provider Service (HIPS) middleware product

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:

• 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 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 Diagnostic Imaging reports to the My Health Record

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

Conformance

The software must:

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

Note: One part of the system will almost always be responsible for the authoring of a diagnostic imaging report. This report is sent to the General Practitioner or Specialist. Under upcoming changes in the law, the report must be uploaded to My Health Record (MHR), implying conformance to the MHR, which implies conformance to the HI Service. Noting that all RIS, regardless of configuration, will need access to the HI Service even if access to MHR is not legally required.

Further to this, connections to MHR and HI Service can be done through integrated services like gateways and enterprise systems (especially in hospitals).

In rare circumstances, if the system being procured does not have an authoring component, then conformance to the MHR does not apply – but conformance to the HI Service remains the same.

If the system connects to the Healthcare Information Provider Service (HIPS) middleware product, the system must conform to the HIPS conformance profile V1.

State and territory requirements

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