Skip to main content
Guide
DG-3073
Status
Active
Version
1.0
Created
Updated

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

In this tutorial, you will;

  • 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

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 Portal if you have not already or sign in to an existing account.

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. Create an account for your organisation on the Agency's form submission platform.

4. After creating an account click the following link to access the online Portal Operator Registration Form to register as a mobile developer. Note, you must be logged into the Agency's form submission platform to access the form.

The Portal Operator Registration Form will require you to verify the identity of all nominated Operator Officers, register your organisation details and specify your proposed application’s use cases and health and wellness outcomes.

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.

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;

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

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.

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. 

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

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