Go to top of page

Reading: 30 minutes 
Registration: 60 minutes
Development: 30 minutes
Total: 2 hours

Quick Intro

More Information
Before jumping on the tutorial guides, download the support documents from the Developer Center website.

In this tutorial, you will;

  • Understand high-level concepts regarding the My Health Record system and the FHIR Gateway
  • Register as a developer for the Gateway
  • Understand your testing obligations
  • Understand guidelines regarding security, consent, incident management and app presentation
  • Understand the content which will be delivered in these guides

The My Health Record system gives individuals, their representatives, and their healthcare providers the ability to view their digital health record in one central online location. There are several mechanisms you can use to connect software to the My Health Record system, if you are unfamiliar with these mechanisms you can review the options here.

This guide is focused on the FHIR Gateway (also previously known as the Mobile Gateway). The FHIR (Fast Healthcare Interoperability Resources) APIs (REST-based) can currently be used for developers to build apps and other products which are targeted towards consumers. The diagram below represents the gateway between the My Health Record system and the end product.

fhir-gateway-connection-diagram

The consumer authenticates themselves using their MyGov credentials. Your product will redirect the users to the MyGov authentication page and receive a token for authenticated users. Your product can then use this token to access the user’s My Health Record.

Throughout these guides a demonstration using Xamarin will be developed, although there are many platforms you can use to develop your product. When registering as a developer for the FHIR Gateway you will need to define your app as either Mobile, Web, or Hybrid. Mobile would be native iOS/Android/etc, Web would be browser based, and Hybrid would be a combination of the two.

The complete FHIR Gateway specifications include many interaction models, however only 2 of these interaction models are currently available to developers:

  • Interaction model 1 and
  • Interaction model 4

Both models are for consumer use and the primary difference is that interaction model 4 includes the use of an intermediary server which you would use to store information between retrieval from the My Health Record system and use within your product. The interaction models are presented in the diagram below.

fhir-gateway-interaction-model

In the following developer guides, interaction model 1 will be used to develop a mobile app. 

Step 1: Developer Registration

Conduct the following registration steps as soon as possible as there may be some lead-time before you are granted access to the Software Vendor Test (SVT) Environment, which is required to progress development.

1. Create an account on the Digital Health Developer Centre if you have not already: https://developer.digitalhealth.gov.au/user/register

2. Download the My Health Record Mobile Developer Welcome Pack and familiarise yourself with the file contents. As these documents will be referred to in more detail throughout this guide.

3. Complete the online Portal Operator Registration Form to register as a developer.

Once you have submitted the form above you can continue with these guides to prepare your development environment however you will need to be granted access to the SVT Environment to progress your development.

Along with access to the SVT you will receive a Test Kit which will include test data and test cases. If you are connecting using interaction model 4 you will also be issued a digital certificate for that server.

All apps granted My Health Record production environment access for the first time will be provisioned with an Application ID (App ID) and Application Secret Access Key (Secret Key). The App ID and Secret Key are both used by the app as part of authentication and authorisation to the My Health Record system. An app with My Health Record production environment access that has a significant update or produces the same app for multiple platforms (e.g., Android and iOS), will need to be provisioned with a separate App ID and Secret Key. Notice of Connection (NOC) testing must be completed, and conformance and compliance declared for each platform version. 

More Information 
You should now review the App changes and upgrades section of My Health Record Managing Your App in Production file contained in the Welcome Pack.

Step 2: Testing Requirements

Once you have completed your app development and internal testing you will be required to undertake 3 formal steps. Steps 1 and 2 can be done in parallel.

1. Contact [email protected] and a team member will walk you through the process of submitting your prototype for review against the FHIR Gateway Guidelines (more information provided below)

2. Complete all relevant test cases (from your Test Kit) and submit the results the My Health Record team on [email protected]. This step is referred to as Notice of Connection (NoC) Self Assessment testing.

3. The My Health Record team will organise a virtual session with your team to demonstrate your product and ensure it is functioning in accordance with the specifications and guidelines. This is referred to as NoC testing.

More Information
Registration, developer community and general enquires: My Health Record Team [email protected] 

For technical and testing support in the test environment: National Infrastructure Operator (NIO) [email protected] 

For production incident management and app changes: System Management [email protected]

Step 3: Guidelines

Within your Welcome Pack you will find 4 Guidelines documents relating to Operations, Consent, Security and Presentation. A summary of the content is detailed below however you should also take the time to familiarise yourself with the content of these documents.

These documents primarily contain requirements, and each contain approximately 10-20. You can identify which requirements are mandatory and which are optional using the normative verb keywords below;

SHALL

When appearing in a conformance requirement, the verb SHALL indicates a mandatory requirement. Its negative form SHALL NOT indicates a prohibition.

SHOULD

When appearing in a conformance requirement, the verb SHOULD indicates a recommendation. Its negative form SHOULD NOT indicates an option that is recommended against

MAY

When appearing in a conformance requirement, the verb MAY indicates an optional requirement.

Operations Guidelines

The requirements found in this document are primarily operational in nature. They cover the forms which shall be submitted, the obligation on you to conform to requirements and specifications, your customer support requirements, incident management obligations and your responsibilities regarding outages, deprecated versions, etc. You must read all 22 requirements in full and 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.

Important
Familiarise yourself with all 11 requirements in the Consent Requirements Guidelines document now, and then return to this guide.

Note
The System Operator reserves the right to defer or reject a developer’s access to the production environment if an app's design does not satisfy the requirements as stated in any of the 4 Guidelines documents.

Security Requirements

The Security Guidelines document is the most comprehensive of the 4 Guidelines documents. Many of these requirements focus on organisational processes which will obviously 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 will be relevant for the actual 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 for responsibility of the requirement.

App Presentation Guidelines

This document is split into 2 sections. The first is to cover 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. Present Medical-related information such as medicine dose, prescriptions, dispense in plain and simple English.  

3. It is important that the provenance of information is clearly stated or can be easily obtained. 

Important
Read the Presentation Requirements and Guidelines document now to familiarise yourself with the principles and requirements. 

Step 4: Managing your app in production

Now that you have read the Operations Guidelines you will understand that you have responsibilities regarding your product once it is live. These responsibilities are primarily related to incidents and changes to your app. The document Managing your app in production must be read prior to your conformance declaration however it does not contain any content which is required for you to begin development.

The table below summarises the types of possible incidents and you can keep these in mind as you develop your product and plan errors, warnings and logging.

Type of incident  

Description  

System

An 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. 

Security

A 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 safety

An event or circumstance that resulted, or could have resulted, in unintended or unnecessary harm to a person.  

Regulatory incident/breach

An identified breach of My Health Record policy, rules, regulations, or legislation. 

Privacy

My Health Record consumers have had their personal information collected, shared, or used in an inappropriate way. 

Fraud

Identified or potential deception intended to result in financial or personal gain. 

Developer app

Any issues with the functions or performance in the app. 

Step 5: Demo app functionality

Throughout these guides we will build the following functionality 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 Medicare.

Conclusion

At this point you should be familiar with the FHIR Gateway and have submitted your online Portal Operator Registration Form. 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