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.
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.
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.|
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.
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.
Familiarise yourself with all 11 requirements in the Consent Requirements Guidelines document now, and then return to this guide.
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.
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.
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.
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.