Skip to main content
Category
Guidance Document
ID
DG-3073
Type
Guide
Standard
Version
1.0
Status
Active
Created date
Updated date

Introduction

This page provides guidance on how to register as a developer for the Gateway. It outlines testing obligations, provides guidelines regarding security, consent, incident management and app presentation, and helps understand the content which will be delivered in these guides.

Pre-requisites

Step 1: Developer Registration

Please register promptly to allow timely access to the Software Vendor Test (SVT) Environment, which is required for development.

Step 1.1. Download the My Health Record Mobile Developer Welcome Pack and review the contents, as they will be referenced throughout this guide.

Step 1.2. Download and complete the My Health Record - Portal Operator Registration Form (PORF) then submit the form to help@digitalhealth.gov.au

The My Health Record - Portal Operator Registration Form (PORF) requires verification of all nominated Operator Officers' identities, your organisation's details, and your application’s intended use cases and health outcomes..

Step 2: Testing Requirements

After completion of app development and internal testing, the complete the following three steps (Steps 1 and 2 can be done concurrently):

Step 2.1. Contact help@digitalhealth.gov.au and a team member will discuss your app integration against the FHIR® Gateway Guidelines (more information provided below)

Step 2.2. Complete all relevant test cases (from your Test Kit) and submit the results to the system operator on healthAPIGatewaySVT@deloitte.com.au. This step is referred to as Notice of Connection (NoC) Self-Assessment testing.

Step 2.3. The Gateway Operator will organise a virtual session with your team to demonstrate your software application is functioning in accordance with the specifications and guidelines. This is referred to as NoC testing.

Step 3: Guidelines

The Welcome Pack includes four Guidelines documents on Operations, Consent, Security, and Presentation, summarised below Please ensure you are familiar with the contents of these documents. 

These documents primarily contain approximately 10-20 requirements each. The normative verb keywords below identify which requirements are mandatory and which are optional.

SHALLWhen appearing in a conformance requirement, the verb SHALL indicates a mandatory requirement. Its negative form SHALL NOT indicates a prohibition.
SHOULDWhen appearing in a conformance requirement, the verb SHOULD indicates a recommendation. Its negative form SHOULD NOT indicates an option that is recommended against
MAYWhen appearing in a conformance requirement, the verb MAY indicates an optional requirement.

Operations Guidelines

This document covers operational requirements such as submission of forms, obligations to conform to requirements and specifications, customer support requirements, incident management obligations, and responsibilities regarding outages and deprecated versions. Please read all 22 requirements in full. Your organisation will be agreeing to these guidelines as part of the declaration process.

Consent Guidelines

The health information contained in a user’s My Health Record is defined as sensitive in the Privacy Act 1988 (Privacy Act), which means that under the Australian Privacy Principles (APPs) developers collecting such information must first obtain a user’s informed consent.

Security Requirements

The Security Guidelines document is the most comprehensive of the 4 Guidelines documents. Many of these requirements include organisational processes which will be outside the scope of this developer guide. However, your organisation will need to be familiar with these Guidelines and meet all mandatory requirements. Section 5 of this document contains requirements which are specifically relevant for development.

You should familiarise yourself with this entire document and you may wish to use the Description section of each requirement to identify the relevant business area in your organisation responsible for the requirement.

App Presentation Guidelines

This document is split into 2 sections. The first section covers core principles of the application and the second focuses on the actual requirements. This document is very important for developers.

The presentation requirements and guidelines are based on a set of core principles. These are; 

1. App interface designs should take into account screen real estate to ensure optimal presentation.

2. Medical information such as medicine dose, prescriptions, dispensation should be presented in plain and simple English.  

3. Provenance of information should be clearly stated or easily obtained. 

Step 4: Managing your app in production

The Operations Guidelines above will provide an understanding of your responsibilities when an app is live. These responsibilities are primarily related to incidents and changes to your app.  

Please read the “Managing your app in production” document prior to your conformance declaration. While the document does not contain content required to begin development, it provides important information to be aware of.
The table below summarises the types of possible to keep in mind as you develop your product and plan errors, warnings and incident logging.

Type of incident  Description  
SystemAn unplanned interruption or degradation to the My Health Record system’s operations which result in a reduction or loss of system functionality. E.g. My Health Record FHIR® API is not responding. 
SecurityA breach of the My Health Record system’s security measures resulting in a threat to the integrity, availability, or confidentiality of the My Health Record system.  
Clinical safetyAn event or circumstance that resulted, or could have resulted, in unintended or unnecessary harm to a person.  
Regulatory incident/breachAn identified breach of My Health Record policy, rules, regulations, or legislation. 
PrivacyMy Health Record consumers have had their personal information collected, shared, or used in an inappropriate way. 
FraudIdentified or potential deception intended to result in financial or personal gain. 
Developer appAny issues with the functions or performance in the app. 

Step 5: Demo app functionality

The following functionality should be built into the app.

1. Authentication Services: Using MyGov to authenticate the user

2. Identification Service: Retrieve patient details and a list of any other people who may have provided authorisation to this user.

3. Consumer documents: Retrieving medications and allergies from the Personal Health Summary, which is data entered by the consumer.

4. Clinical Document Services: Retrieve clinical documents created by a healthcare provider

5. Generic Document Services: Retrieve document lists and specific documents

6. Medicare Information: Retrieve MBS and PBS documents from the My Health Record which have originated from

Conclusion

At this point you should be familiar with the FHIR® Gateway and have submitted your My Health Record - Portal Operator Registration Form (PORF). You may still be awaiting your SVT access and Test Kit. You should also be familiar with the Welcome Pack content and should have read the 4 Guidelines documents in depth. Continue to the next guide to prepare your development environment.

View All | Next: Environment Setup and Authentication - My Health Record FHIR Gateway Developer Guide 2