0% found this document useful (0 votes)

35 views94 pages

MyHealthRecordFHIRGateway APISpecification v2.0.0

My Health Record FHIR® Gateway API Specification

Uploaded by

miahkota

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

35 views94 pages

MyHealthRecordFHIRGateway APISpecification v2.0.0

My Health Record FHIR® Gateway API Specification

Uploaded by

miahkota

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 94

Digitally signed by Australian Digital Health Agency

Date: 2019.06.07 10:35:13 +10'00'

My Health Record FHIR® Gateway

API Specification
17 June 2019
v2.0.0
Approved for external use
Document ID: DH-2751:2018
Australian Digital Health Agency
Level 25, 175 Liverpool Street
Sydney, NSW 2000
Australia
www.digitalhealth.gov.au

Acknowledgements
Council of Australian Governments
The Australian Digital Health Agency is jointly funded by the Australian Government and all state and territory
governments.
Regenstrief Institute (LOINC)
This material contains content from LOINCTM (http://loinc.org). The LOINC table, LOINC codes, LOINC panels and
forms file, and LOINC linguistic variants file are copyright © 1995-2015, Regenstrief Institute, Inc. and the Logical
Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at
https://loinc.org/terms-of-use/. LOINC is a trademark of Regenstrief Institute, Inc., registered in the United States.
IHTSDO (SNOMED CT)
This material includes SNOMED Clinical TermsTM (SNOMED CT®) which is used by permission of the International
Health Terminology Standards Development Organisation (IHTSDO). All rights reserved. SNOMED CT® was originally
created by The College of American Pathologists. “SNOMED” and “SNOMED CT” are registered trademarks of the
IHTSDO, (http://www.ihtsdo.org/).
HL7 International
This document includes excerpts of HL7TM International standards and other HL7 International material. HL7
International is the publisher and holder of copyright in the excerpts. The publication, reproduction and use of such
excerpts is governed by the HL7 IP Policy (see http://www.hl7.org/legal/ippolicy.cfm) and the HL7 International
License Agreement. HL7 and CDA are trademarks of Health Level Seven International and are registered with the
United States Patent and Trademark Office.

Disclaimer
The Australian Digital Health Agency (“the Agency”) makes the information and other material (“Information”) in this
document available in good faith but without any representation or warranty as to its accuracy or completeness. The
Agency cannot accept any responsibility for the consequences of any use of the Information. As the Information is of
a general nature only, it is up to any person using or relying on the Information to ensure that it is accurate,
complete and suitable for the circumstances of its use.
Document control
This document is maintained in electronic form and is uncontrolled in printed form. It is the responsibility of the user
to verify that this copy is the latest revision.
Copyright © 2019 Australian Digital Health Agency
This document contains information which is protected by copyright. All Rights Reserved. No part of this work may be
reproduced or used in any form or by any means – graphic, electronic, or mechanical, including photocopying,
recording, taping, or information storage and retrieval systems – without the permission of the Australian Digital
Health Agency. All copies of this document must include the copyright and other information contained on this page.
My Health Record FHIR® Gateway
API Specification v2.0.0

Document information
Key information
Owner Executive General Manager, Infrastructure Operations

Contact for enquiries Australian Digital Health Agency Help Centre

t: 1300 901 001
e: help@digitalhealth.gov.au

Product version history

Product Date Release comments
version

1.0.0 30 Jun 2016 First Public Release

1.0.0-hotfix 25 Jul 2016 Hot Fix Release

1.2.0 18 Jun 2017 Production Release for API v1.2.0

1.3.0 22 Jun 2018 Production Release for API v1.3.0

2.0.0 17 Jun 2019 Production Release for API v2.0.0

17 June 2019 Approved for external use 3 of 94

DH-2751:2018
Australian Digital Health Agency

Table of contents
1 Introduction ....................................................................................................... 6
1.1 Purpose ...................................................................................................... 6
1.2 Intended audience ....................................................................................... 6
1.3 Scope ......................................................................................................... 6
2 REST Model ......................................................................................................... 7
2.1 Key characteristics ....................................................................................... 7
2.2 API Versioning ............................................................................................. 9
3 API Catalogue ................................................................................................... 10
3.1 Authentication services ............................................................................... 10
3.1.1 Individual Initial Authentication (OAuth) ........................................... 10
3.1.2 Get or Refresh Token ..................................................................... 13
3.1.3 Initial Provider Authentication (JWT) ................................................ 15
3.2 Identification service .................................................................................. 17
3.2.1 Get Record List (GET) ..................................................................... 18
3.2.2 Get Patient Details (GET) ................................................................ 21
3.3 Medicare Information ................................................................................. 28
3.3.1 Get PBS Items (GET) ...................................................................... 28
3.3.2 Get MBS Items (GET) ..................................................................... 32
3.4 Generic document services ......................................................................... 35
3.4.1 Get Document (GET) ...................................................................... 35
3.4.2 Search Document List (GET) ........................................................... 37
3.5 Consumer documents ................................................................................. 41
3.5.1 Get Personal Health Summary - Medications (GET) ............................ 41
3.5.2 Update Personal Health Summary - Medications (POST) ..................... 43
3.5.3 Update Personal Health Summary - Medications (PUT)........................ 47
3.5.4 Update Personal Health Summary - Medications (DELETE) .................. 51
3.5.5 Get Personal Health Summary - Allergies (GET) ................................. 54
3.5.6 Update Personal Health Summary – Allergies (POST) ......................... 56
3.5.7 Update Personal Health Summary – Allergies (PUT) ........................... 59
3.5.8 Update Personal Health Summary - Allergies (DELETE) ....................... 64
3.6 Clinical document services .......................................................................... 66
3.6.1 Prescription and Dispense List (GET) ................................................ 66
3.6.2 Get Allergies List (SHS) (GET) ......................................................... 73
Appendix A Common ............................................................................................. 77
Appendix B Referenced Artefacts .......................................................................... 82
Appendix C Personal Health Summary................................................................... 83
Appendix D Patient Search by Provider – Alternative Search Criteria .................... 86

4 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Appendix E Extension Registry .............................................................................. 89

Appendix F Terminologies ..................................................................................... 91
Appendix G Operations .......................................................................................... 92
Acronyms ................................................................................................................. 93
References ............................................................................................................... 94

17 June 2019 Approved for external use 5 of 94

DH-2751:2018
Australian Digital Health Agency

1 Introduction
1.1 Purpose
This document provides an overview of the API specifications required by
developers to connect applications (apps) to the My Health Record system. This
document describes API requests, API responses, OperationOutcome details, and
error conditions that apply to application transactions.

1.2 Intended audience

This document is intended for use by Fast Healthcare Interoperability Resources
(FHIR®) API consumers to understand the API signature exposed by the My Health
Record system. This includes information about request messages, response
messages, error handling and request processing logic. This document will serve as
an input to the National Infrastructure Operator (NIO) Build team for the
development and implementation of the solution. This document is also intended as
an input to the NIO Test team for the purpose of defining test scripts.

1.3 Scope
This document is limited to discussing the following three sections:

• Section 1 – Introduction: The introduction outlines the document’s

purpose, scope and references.
• Section 2 – REST Model: This section describes the key characteristics of
the REST model and how they are used in the APIs developed in the My
Health Record system.
• Section 3 – API Catalogue: This section describes the APIs exposed via
the API Gateway channel, API descriptions, API message specifications and
a list of error codes that the APIs can return as an OperationOutcome.
It does not cover the following areas:

• Guideline for RESTful API: This document assumes that the

implementers are familiar with RESTful API concepts.
• FHIR® Specification: This document assumes that the implementers are
familiar with basic FHIR® concepts.

6 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

2 REST Model
REST (Representational State Transfer) relies on a stateless, client-server,
cacheable communications protocol and, in virtually all cases, the HTTP protocol is
used.

REST is an architecture style for designing networked applications. Rather than

using complex mechanisms such as CORBA, RPC or SOAP to connect between
machines, simple HTTP is used to make calls between machines.
The My Health Record system FHIR API has been implemented using the REST
model, and the following guiding principles have been followed:
• Platform independence;
• Programming language independence;
• Standards-based (runs on top of HTTP);
• Can easily be used in the presence of firewalls.
The following subsections give an overview of some of the key characteristics of the
My Health Record system FHIR API and the versioning strategy that is applied to
both the FHIR API Specification as a whole and its associated interactions.

2.1 Key characteristics

Resources, which are identified by logical URLs.
Both state and functionality are represented using resources. Client systems make
requests against My Health Record system resources, either in aggregate or a
specific resource.

No connection state: interaction is stateless.

Each new request should carry all the information required to complete it, and must
not rely on previous interactions with the same client.

HTTP Interaction: GET, POST, PUT or DELETE HTTP requests against My Health
Record system resources.
Request Headers vary between API interactions.
Refer to the respective API sections in this document for more details.
Common request headers in use are:

• ‘Accept’: This is an optional value. The value of ‘Accept’ specifies the

response format. Valid response formats are: ‘application/xml+fhir’ or
‘application/json+fhir’.
• ‘Authorization’: This is the OAuth token generated by the My Health Record
system. This is mandatory.
• ‘App-Id’: This is the Application ID assigned to the application. This is
mandatory.
• ‘App-Version’: This is the application version as presented to the user. This
is mandatory.
• ‘Platform-Version’: This optional header is used to identify the version of
the intermediary server for apps based on interaction models 4 and 5.

17 June 2019 Approved for external use 7 of 94

DH-2751:2018
Australian Digital Health Agency

Response Codes: HTTP response codes appropriate for the result of the request.
While the exact meaning of the code varies depending on the API interaction, the
general rules are:

• 200 – The request was successful.

• 201 – The request has been successful and a new resource has been
created.
• 204 – The requested interaction was successful and there is no response
body.
• 307 – Please repeat the request using the provided URI. Subsequent
requests can use the old URI.
• 400 – Your request was improperly formatted. You should verify that your
request conforms to this specification and re-issue the request in a
properly formatted manner.
• 403 – The request was not allowed because the request did not pass
authentication or you do not have the proper access rights to the target.
• 404 – The requested resource does not exist.
• 500 – My Health Record system failed to process the request because of an
error. These responses should be reported to the My Health Record support
team as these can represent a bug in the system.
• 501 – My Health Record system does not support the functionality required
to fulfil the request.
• 503 – My Health Record system is undergoing maintenance or is otherwise
temporarily unavailable for API queries.
Response Entities: all GET methods respond with the JSON or XML of the
resource(s) being requested.

Authentication: My Health Record system authenticates each application request

individually. The application provides the request with the Application ID provided
during the registration process.

Application ID and Secret Client Access Key: Will be provided during the
registration process by the My Health Record System Operator.

8 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

2.2 API Versioning

The FHIR API of the My Health Record system is versioned according to the
following numbering scheme:

majorVersion.minorVersion.patchVersion

This numbering scheme is aligned with Semantic Versioning Specification (SemVer)

v2.0.01, which has been widely adopted across the software development
community. Its key points are reflected by the following table.

Table 1 – Semantic Versioning

Version Backwards Change type

type compatible

Major NO Functionality changes, e.g.

removed operations;
alignment with new FHIR Specification version

Minor Yes Functionality changes, e.g.

additional operations

Patch Yes Bug fixes

Importantly, the version number of the FHIR API is reflected in the URLs of all API
interactions. To allow for an easy transition to newer versions of the FHIR API,
applications should be developed in ways that allow the setting of the FHIR API
version number at a central location and the utilisation of this setting for all API
requests (i.e. dynamic inclusion of the API version number in the URLs of all API
requests).

1
http://semver.org/spec/v2.0.0.html

17 June 2019 Approved for external use 9 of 94

DH-2751:2018
Australian Digital Health Agency

3 API Catalogue
This section lists the APIs in the My Health Record system, organised into six logical
groups:

• Authentication Services provides interactions for interacting with the My

Health Record system by establishing the identity of the user.
• Identification Services provides interactions to retrieve patient details
and record details from the My Health Record system.
• Medicare Information provides interactions to retrieve Medicare
information from the My Health Record system, which includes Medicare
Benefits Scheme (MBS) and Pharmaceutical Benefits Scheme (PBS) data.
• Generic Document Services provides interactions to retrieve a document
or a document list from the My Health Record system.
• Consumer Document Services provides interactions to retrieve and
update consumer-entered documents from the My Health Record system.
• Clinical Document Services provides interactions to retrieve specific
clinical document information from the My Health Record system such as
prescription and dispense, and allergies information.

3.1 Authentication services

Three APIs are classified under this group:

• Individual Initial Authentication (OAuth)

• Initial Provider Authentication (JWT)
• Get or Refresh Token

3.1.1 Individual Initial Authentication (OAuth)

3.1.1.1 Description

This API is used to validate an individual’s identity (username, password and secret
question/answer with myGov – identity provider for government services).

To proceed with Individual Authentication, the following criteria must be met:

• Application is registered with the My Health Record system.
• Individual has a myGov account.
• Individual has one or more My Health Record(s) linked to his/her myGov
account.

3.1.1.2 Authentication Flow

The below figure depicts the successful authentication and authorisation flow for an
application (note, step 3 is an example only).

10 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Figure 1 – Authentication and Authorisation Flow

3.1.1.3 Message Specification

OAuth 2.0 framework specification is available at: http://tools.ietf.org/html/rfc6749

17 June 2019 Approved for external use 11 of 94

DH-2751:2018
Australian Digital Health Agency

3.1.1.4 Request Message

Table 2 – Individual Authentication-Request Message

Resource URI [fqdn]/api/oauth/v1/authorize/login

HTTP Method GET

Request Headers Data Format Min Max Cardinality Remarks

Type Length Length

Request
Parameters/ Search
Support

client_id UUID UUID 36 36 1..1 Client identifier for the

application (aka App ID)

response_type string string 4 4 1..1 The value MUST be text

as "code" for requesting
an authorisation code

redirect_uri string string - - 1..1 Callback URL for the

application to handle
authorisation code, to be
provided by the
developer during the
application registration
process in the Production
Environment Access
Request Form.

scope string string - - 1..1 API scope to be provided

to the developer during
the application
registration process

3.1.1.5 Response Message

The My Health Record system returns an HTML page to the application, and end
users get authenticated with their myGov username/password and secret
question/answer.
An authorisation code is generated against the redirect URL. This is depicted below:

[redirect_uri]?code=[authorization_code]

Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

3.1.1.6 Error Scenarios

Refer to the “Access Token Error Conditions” section under “OAuth2_0” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

12 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

3.1.2 Get or Refresh Token

3.1.2.1 Description
This API provides the ability to obtain access tokens for subsequent requests for individual
access to the My Health Record system. It also provides the ability to refresh access tokens
upon access token expiry.
To generate a token, the following criteria must be met:

• Application is registered with the My Health Record system.

• Individual has a myGov account.
• Individual has one or more My Health Record(s) linked to his/her myGov
account.

3.1.2.2 Message Specification

OAuth 2.0 framework specification is available at: http://tools.ietf.org/html/rfc6749

3.1.2.3 Request Message to get access token

Table 3 – Get Access Token-Request Message

Resource URI [fqdn]/api/oauth/v1/token

HTTP Method POST

Request Headers Data Format Min Max Cardinalit Remarks

Type Lengt Lengt y
h h

Content-Type string application/x-www-

form-urlencoded

Request Parameters/
Search Support

client_id UUID UUID 36 36 1..1 Client identifier for

the application (aka
App ID)

client_secret UUID UUID 36 36 1..1 Client secret for the

application (aka App
secret)

grant_type string string 18 18 1..1 The value MUST be

“authorization_code”
to get the access
token

redirect_uri string string - - 1..1 Callback URL for the

application to handle
authorisation code, to
be provided by
developer during the
application
registration process

format string string 4 4 1..1 The value MUST be

“JSON”

Code string string 32 32 1..1 Authorisation code

generated in 3.1.1

17 June 2019 Approved for external use 13 of 94

DH-2751:2018
Australian Digital Health Agency

3.1.2.4 Request Message to refresh access token

Table 4 – Refresh Access Token – Request Message

Resource URI [fqdn]/api/oauth/v1/token

HTTP Method POST

Request Headers Data Format Min Max Cardinality Remarks

Type Length Length

content-type string string 33 33 1..1 application/x-www-

form-urlencoded

Authorization string string 102 102 0..1 Base64 encoded of

“client_id:client_secret”

Request
Parameters/
Search Support

client_id UUID UUID 36 36 1..1 Client identifier for the

application (aka App
ID)

client_secret UUID UUID 36 36 1..1 Client secret for the

application (aka App
secret)

grant_type string string 13 13 1..1 The value MUST be

“refresh_token” to
refresh the access
token

format string string 4 4 1..1 The value MUST be

“JSON”

refresh_token string string 46 46 1..1 Refresh token

generated while
generating the access
token in step 3.1.2.3

3.1.2.5 Response Message

The access token is returned in JSON format.

Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

3.1.2.6 Token Expiration Period

• Access token expires in 7200 seconds (2 hours)

• Refresh token expires in 15768000 seconds (6 months)
Note: Under interaction model #4, a consumer’s OAuth tokens (both the access
token and the refresh token) must not be used by the intermediary server if that
consumer has not accessed the application for more than 6 months.

14 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

3.1.2.7 Error Scenarios

During authentication, for all success and failure cases system redirects the flow to
the “redirect_url” as registered with My Health Record System.

For all other cases where My Gov denies authentication due to incorrect credentials,
the system says on the login page with showing the appropriate error messages.

Refer to the “Refresh Token Error Conditions” section under “OAuth2_0” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

3.1.3 Initial Provider Authentication (JWT)

3.1.3.1 Description

This API is used to validate a healthcare provider’s identity to allow the indirect
connection of a mobile application to MHR through an Intermediary Server.
To proceed with Provider Authentication, the following criteria must be met:

• Application is registered with the My Health Record system.

• Healthcare provider has either a HPI-I or a Local System Identifier (LSI).
• The HPI-I or LSI is linked to a valid HPI-O.

3.1.3.2 Authentication Flow

The steps below describe the successful authentication and authorisation flow for an
application

1. Healthcare provider accesses the app by entering their HPI-I/LSI and password
on their mobile device.

2. The device passes the login information to the vendor intermediary server to
authenticate the user.
3. Intermediary server fires the Initial Provider Authentication request to the MHR
mobile gateway to authenticate the user with a JSON Web Token (JWT).

4. Mobile gateway triggers access validation internally to verify if the calling

application has access to the invoked API:

5. Based on the validation result, system generates a token and returns back to
the calling system.

3.1.3.3 Message Specification

OAuth 2.0 framework specification is available at: http://tools.ietf.org/html/rfc6749

More information on JWT can be found at:

https://tools.ietf.org/html/rfc7519#page-6

3.1.3.4 Request Message

Table 5 – Provider Authentication-Request Message

Resource URI [fqdn]/api/oauth/token/provider

HTTP Method POST

17 June 2019 Approved for external use 15 of 94

DH-2751:2018
Australian Digital Health Agency

Request Headers Data Format Min Max Cardinality Remarks

Type Length Length

Content-Type string application/x-www-form-

urlencoded

Request
Parameters/ Search
Support

grant_type string string 43 43 1..1 The value MUST be set

to:
urn:ietf:params:oauth:g
rant-type:jwt-bearer

assertion string string - - 1..1 Must be set to the JWT

bearer token, base64url-
encoded.

format MIME- MIME- 4 4 0..1 The supported value is

type type ‘json’.

userName string string - - 1..1 This captures the

username of the
individual provider. This
is provided by the
vendor intermediary
server.

organisationName string string - - 1..1 This captures the

organisation name of the
individual provider. This
is provided by the
vendor intermediary
server.

deviceID string string - - 0..1 This captures the mobile

device ID of the
individual provider. This
is provided by the
vendor intermediary
server.

deviceMake string string - - 0..1 This captures the mobile

device make of the
individual provider. This
is provided by the
vendor intermediary
server.

deviceModel string string - - 0..1 This captures the mobile

device model of the
individual provider. This
is provided by the
vendor intermediary
server.

3.1.3.5 JWT Format

The Intermediary Server will trigger the API with the JSON Web Token (JWT) that
has been generated. The JWT contains the following authentication claims in its
body:

16 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Table 6 – JWT Claims

Claim Description Cardinality Sample

iss The service's client_id, as determined 1..1 E.g. "28198d27-c475-

during registration with the EHR's 4695-83d3-
authorization server. 1f1f8256e000"

aud The EHR authorization server's "token 1..1 E.g.

URL" (the same URL to which this "https://localhost/oauth
authentication JWT will be posted). _callback"

exp Expiration time integer for this 1..1 E.g. "1477025181"

authentication JWT, expressed in
seconds since the "Epoch" (1970-01-
01T00:00:00Z UTC). This time MUST be
no more than five minutes in the future.

iat The time the assertion was issued (iat) 1..1 E.g. "1477025181"
expressed in seconds since the "Epoch"
(1970-01-01T00:00:00Z UTC).

jti A nonce string value that uniquely 1..1 E.g. "uuid:98145613-

identifies this authentication JWT bearer 756b-445f-909f-
token. d16d6c49d000"

organisationID Custom JWT claim that captures the 1..1 E.g.

organisation ID of the HPI-O. "8003629900020187"

userID Custom JWT claim that captures the user 1..1 E.g.
identifier, the identifier can be one of the "8003611566666701"
following:
• HPI-I
• Local System Identifier (LSI)

3.1.3.6 Response Message

The access token is returned in JSON format. The response contains the following
elements:

‘scope’, ‘expires_in’, ‘access_token’ and ‘token_type’.

The value of ‘token_type’ is always ‘Bearer’.

Refer to "My Health Record FHIR Gateway - Sample Requests and Responses"
further details.

3.1.3.7 Error Scenarios

Refer to the “Provider Authentication Error Conditions” section under “OAuth2_0”

tab of My Health Record FHIR® Gateway – Error Mapping document to find the
applicable FHIR® API Error details.

3.2 Identification service

There are two APIs classified under this group:

• Record List (GET)

• Patient Details (GET)

17 June 2019 Approved for external use 17 of 94

DH-2751:2018
Australian Digital Health Agency

3.2.1 Get Record List (GET)

3.2.1.1 Description

This API provides the ability to retrieve the list of records the individual is permitted
to access and returns a bundle containing the RelatedPerson resource for each
accessible record such as:

• Self
• Authorised Representative types:
o Under 18 - Parental Responsibility
o Under 18 - Legal Authority
o Under 18 - Otherwise Appropriate Person
o 18 and Over - Otherwise Appropriate Person
o 18 and Over - Legal Authority
• Nominated Representative
o Full Access Nominated Representative
o Nominated Representative
This API is accessible by consumers only.

3.2.1.2 Message Specification

Resource served on the REST interface (Conformance.rest.resource.type):

‘RelatedPerson’

FHIR®-based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/relatedperson.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’).
For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.2.1.3 Versioning and History

• API Version: ‘v2.0.0’.

• FHIR® Version (Conformance.fhirVersion): ‘1.4.0’.
• Resource Instance Version (Conformance.rest.resource.versioning): ‘no-
version’. ‘VersionId’ meta-property is not supported (server) or used
(client).
• History (Conformance.rest.resource.readHistory): ‘false’. For API v2.0.0,
the server is not able to return past versions. ‘vRead’ interaction is not
supported.

18 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

3.2.1.4 Request Message

Table 7 – Record Details-Request Message

Resource URI [fqdn/fhir/v2.0.0]/RelatedPerson

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (search)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

Request
Parameters
(searchParam)

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir
(to represent it as
JSON).

3.2.1.5 Content and Terminology

The tables below summarise My Health Record Specific Extension and ValueSet as
applicable to the Get Record List API.

Content Extension: Relationship Type

Table 8 – Content Extension: Relationship Type

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/relationship-type
URL:

Name: Relationship Type

File Name: • StructureDefinition-relationship-type.xml

• StructureDefinition-relationship-type.json

This is an extension on the RelatedPerson.relationship. More information can be found at Appendix E

Extension Registry section.

17 June 2019 Approved for external use 19 of 94

DH-2751:2018
Australian Digital Health Agency

Terminology: Relationship Type Code

Table 9 – Terminology: Relationship Type Code

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/ValueSet/relationship-type
URL:

Name: Relationship Type Code

File Name: • ValueSet-relationshiptype.xml

• ValueSet-relationshiptype.json
• CodeSystem-relationship-type.xml
• CodeSystem-relationship-type.json

Code Definition

Code Display Definition

RT001 Self Self

RT002 Under 18 - Parental Responsibility Under 18 - Parental Responsibility

RT003 Under 18 - Legal Authority Under 18 - Legal Authority

RT004 Under 18 - Otherwise Appropriate Person Under 18 - Otherwise Appropriate Person

RT005 18 and Over - Legal Authority 18 and Over - Legal Authority

RT006 18 and Over - Otherwise Appropriate Person 18 and Over - Otherwise Appropriate
Person

RT007 Full Access Nominated Representative Full Access Nominated Representative

RT008 Nominated Representative Nominated Representative

The ValueSet is being Referenced from

http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/relationship-type. More information can
be found at TerminologiesExtension Registry section.

3.2.1.6 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘RelatedPerson’ resources in either XML or JSON format.

Refer to "My Health Record FHIR Gateway - Sample Requests and Responses"
further details.

Refer to the “GetRecordList” tab in the My Health Record – API Mapping document
in for more details on the response mapping.

3.2.1.7 OperationOutcome Codes

The API returns error, warning and information messages that provide detailed
information about the outcome of attempted system interaction. They are provided
as a direct system response, or component of one, where they provide information
about the outcome of the interaction.
HTTP error codes that are applicable to this service will be transmitted in the
response header along with the OperationOutcome details in the response body.
Refer to the “Get Record List (GET)” section under “FHIR API Error Cases” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

20 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.2.2 Get Patient Details (GET)

3.2.2.1 Description

This API offers the following capabilities:

• Consumer and provider can retrieve (access control logic applied)

individual’s demographic details as available in the My Health Record
system.
• Provider can verify if a particular patient exists in the My Health Record
system without gaining access to the record.
• Provider can gain access to a particular patient’s record to view the
associated details.
This API is accessible by both consumers and providers.

3.2.2.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type): ‘Patient’

FHIR®-based resource reference (Conformance.rest.resource.profile) is available at:

• http://hl7.org/fhir/2016May/patient.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’).

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

The server supports both XML and JSON transactions. The value can be
‘application/xml+fhir’ (to represent it as XML) or ‘application/json+fhir’ (to
represent it as JSON). (Conformance.format = "xml" or "json”).
The definition of the OperationDefinition (Conformance.rest.operation.definition)
used for the custom FHIR® operation: $access:
More details on the ‘$access’ can be found in Operations section.

3.2.2.3 Versioning and History

• API Version: ‘v2.0.0’.

• FHIR® Version (Conformance.fhirVersion): ‘1.4.0’
• Resource Instance Version (Conformance.rest.resource.versioning): ‘no-
version’. ‘VersionId’ meta-property is not supported (server) or used
(client).
• History (Conformance.rest.resource.readHistory): ‘false’. For API v2.0.0,
the server is not able to return past versions. ‘vRead’ interaction is not
supported.

17 June 2019 Approved for external use 21 of 94

DH-2751:2018
Australian Digital Health Agency

3.2.2.4 Request Message

The table below summarises the request message to get the individual’s
demographic detail when accessed by the individual (consumer).

Table 10 – Patient Details-Request Message

Resource URI [fqdn/fhir/v2.0.0]/Patient/[id]

Note: the [id] is the logical identifier of the patient to be retrieved. If [id] is not
passed in the query string, then the Patient API retrieves the demographics of
logged-in user.
Additional validation is performed on the [id] supplied in the URI to check if the
logged-in user is authorized to perform any operation to the user in context.

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

Request
Parameters
(searchParam)

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

My Health Record system enables capability for the providers to check whether a
particular patient exists in the system or not without gaining the access to the
record. This can be achieved by using the “_element” search on patient’s ID. The
system supports only “_element=identifier” and if the patient exists, the system
returns only the ‘id’, ‘identifier’ and ‘active’ element associated with the patient
resource. Please refer to Appendix Item: Access Policy for Providers for more
details.
The table below summarises the request message when a provider (e.g. practitioner) wants to
verify if a particular patient exists in the My Health Record system.

Table 11 - Verify Patient Exists in My Health Record system - Request Message (Provider)

22 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Resource URI [fqdn/fhir/v2.0.0]/Patient

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (search)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

Request
Parameters
(searchParam)

identifier string string 16 16 0..1 IHI Number of the

patient.
A validation is
performed on the IHI in
the URI to check if it
meets the My Health
Record IHI criteria.
If the IHI number is not
available for the
patient, the search can
be performed with
‘Medicare Card Number’
or ‘DVA File Number’
can be sent as the
search criteria using the
custorm search
parameter ‘coverageId’
Either of identifier or
coverageId is
mandatory for
searching the patient.

coverageId token token - - 0..1 This is custom search

parameter. Use this in
the following format:
coverageId
=[system]|[code]
Refer to section Patient
Search by Provider –
Alternative Search
Criteria section for
more detail.

17 June 2019 Approved for external use 23 of 94

DH-2751:2018
Australian Digital Health Agency

Either identifier or
coverageId is
mandatory for
searching the patient.

_elements string string 10 10 0..1 Allowed value is

‘identifier’.
Use
“_element=identifier”
as search parameter
when the provider is
interested to check if
patient (corresponding
to the identifier
provided in the request)
exists in the My Health
Record system or not.
System does not
support any other
‘_elements’ option.
Note: This Search
option is not available
for the consumer.

_format MIME- MIME- 3 21 0..1 The suggested values

type type are application/xml+fhir
(to represent it as XML)
OR
application/json+fhir
(to represent it as
JSON).

The table below summarises the request message when a provider (e.g.
practitioner) wants to gain access to a patient’s record. Providers are required to
gain access to patient’s record to view relevant details.

Table 12 - Gain Access to Patient Record - Request Message (Provider)

Resource [fqdn/fhir/v2.0.0]/Patient/[id]/$access (if the logical Id is available)

URI [fqdn/fhir/v2.0.0]/Patient/$access (if search patient with demographic details or IHI)

‘$access’ is a custom FHIR® operation on the patient resource. More details can be
found at Operations section.
The [id] in the URI is the logical identifier of the patient.

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method POST

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

24 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

App-Version string - - - 1..1 This is the application version

as presented to the user.
This is mandatory.

Platform- String 0..1 Client (endpoint) platform

Version product and version from
which the app is executed.

content-type string string 20 21 1..1 application/xml+fhir (or)

application/json+fhir
This is the MIME type of the
body of the request

Request
Parameters
(search
Param)

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

Request The request body should

Body contain a ‘Parameters’
(Parameter resource containing the
name) following list of
parameters

subject Patient XML/JSON - - 0..1 Use the IHI number if the

logical identifier of the
patient is unknown.
The provider can also gain
access with supplying
demographic details in the
request body. Refer to
section Patient Search by
Provider – Alternative Search
Criteria section for more
detail and the
‘OperationDefinition.xml’
attached in section This API
is accessible by both
consumers and providers.
Message Specifications for
more details.

accessType String String 10 15 1..1 The values of accessType

parameter can be:
'GeneralAccess','AccessCode',
'EmergencyAccess'

accessCode String String - - 0..1 This field is conditional

mandatory.
If the value of 'accessType'
parameter is 'AccessCode',
then a value of 'accessCode'
parameter has to be sent as
well.

17 June 2019 Approved for external use 25 of 94

DH-2751:2018
Australian Digital Health Agency

In the scenario where the provider wants to gain access to the patient’s
demographic details, ‘POST’ request is initiated using patient’s ‘id’ (Logical
identifier) or IHI (business identifier) or demographic detail. This is done by
invoking ‘$access’ custom FHIR operation on the patient resource. Please refer to
Appendix section Provider Access: Status and Types as applicable to the provider to
gain access to the patient details.

3.2.2.5 Content and Terminology

The table below summarises My Health Record Specific Extension and ValueSet as
applicable to the Get Patient Details API.

Content Extension: Indigenous Status

Table 13 – Content Extension: Indigenous Status

Defining http://hl7.org.au/fhir/StructureDefinition/indigenous-status
URL:

Name: Indigenous Status

Sample: <extension url="http://hl7.org.au/fhir/StructureDefinition/indigenous-status">

This is an extension on the Patient.

Terminology: Indigenous Status Code

Table 14 – Terminology: Indigenous Status Code

Defining http://meteor.aihw.gov.au/content/index.phtml/itemId/602543#Codes
URL:

Name: Indigenous Status Codes

Sample: 1- Aboriginal but not Torres Strait Islander origin

Code Definition

Code Display Definition

1 Aboriginal but not Torres Strait Islander Aboriginal but not Torres Strait Islander origin
origin

2 Torres Strait Islander but not Aboriginal Torres Strait Islander but not Aboriginal origin
origin

3 Both Aboriginal and Torres Strait Islander Both Aboriginal and Torres Strait Islander
origin origin

4 Neither Aboriginal nor Torres Strait Neither Aboriginal nor Torres Strait Islander
Islander origin origin

26 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

9 Not stated/inadequately described Not stated/inadequately described

The value set is being referenced from

http://meteor.aihw.gov.au/content/index.phtml/itemId/602543#Codes

3.2.2.6 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ resources in either XML or JSON format if there is no IHI passed in
the URI query string.

When accessed by the consumer, a bundle containing a list of patients for which the
logged in user has authorized the application to access is retrieved. The list will
contain at least one entry. The normal case is that the list will contain the patient
record for the logged-in user ('self' details), but this is not always the case. The
patient may have access to records for other patients, and may exclude their own
record from view.

The system returns a ‘Patient’ resource corresponding to the patient’s logical

identifier as provided in the request.
When the API is accessed by the provider to verify if a particular patient exists in
the My Health Record system (search), a bundle resource is served which contains
entries of ‘Patient’ resource with the ‘identifier’ and the ‘active’ element populated.
An extension (‘patient-access-criteria’) on the ‘Bundle.search.mode’ has been
added to provide more information about the access restriction as required to
access the patient demographic details.
The API can also be accessed by the provider to gain access to a patient record. In
this case, a ‘Parameter’ resource is returned which consist of the resource access
status ('WithoutCode', 'WithCode' or 'AccessGranted') along with the requested
patient details (if available).

Refer to "My Health Record FHIR Gateway - Sample Requests and Responses"
further details.
Refer to the “GetPatientDetails” tab in the My Health Record – API Mapping
document for more details on the response mapping.

3.2.2.7 OperationOutcome Codes

The API returns error, warning and information messages that provide detailed
information about the outcome of attempted system interactions. They are provided
as a direct system response, or component of one, where they provide information
about the outcome of the operation.
HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.
Refer to the “Get Patient Details (GET) & Get Patient Details (POST)” section under
“FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
the All APIs exposed through My Health Record System.

17 June 2019 Approved for external use 27 of 94

DH-2751:2018
Australian Digital Health Agency

3.3 Medicare Information

There are two APIs classified under this group:
• PBS Items (GET)
• MBS Items (GET)

3.3.1 Get PBS Items (GET)

3.3.1.1 Description

This API provides the ability to retrieve PBS details in the form of a bundle of
ExplanationOfBenefit FHIR® resources from the My Health Record system. A
maximum of 99 resources is returned in the response.

This API is accessible by both consumers and providers.

3.3.1.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘ExplanationOfBenefit’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/explanationofbenefit.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).
The server supports both XML and JSON transactions. The value can be
‘application/xml+fhir’ (to represent it as XML) Or ‘application/json+fhir’ (to
represent it as JSON). (Conformance.format = "xml" or "json”).

3.3.1.3 Versioning and History

• API Version: ‘v2.0.0’.

3.3.1.4 Request Message

Table 15 – PBS Items-Request Message

Resource URI [fqdn/fhir/v2.0.0]/ExplanationOfBenefit

28 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Lengt Lengt
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application version

as presented to the user. This
is mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

Request
Parameters
(searchParam)

patientreference intege integer - - 1..1 Logical identifier of the patient.

r Additional validation is
performed on the
patientreference in the URI to
check if the logged in user is
authorized to perform any
operation on the provided
patientreference.

coverage.plan string string 3 3 1..1 Allowed value: ‘PBS’

created date ‘ge’yyyy 12 12 0..1 From Date is a search criteria

-mm-dd to select the
ExplanationOfBenefit whose
start date is after the specific
period.
The date format must be
prefixed with the value of ‘ge’
to indicate the created date
must be greater-than or equal
to the provided date.
Example: ge2016-05-20

created date ‘le’yyyy 12 12 0..1 To Date is a search criteria to

-mm-dd select the ExplanationOfBenefit
whose start date is before the
specific period.
The date format must be
prefixed with the value of ‘le’
to indicate the created date
must be less-than or equal to
the provided date.
Any future date provided in
the request for ‘le’ will be
defaulted to server current
date.
Example: le2018-07-14

17 June 2019 Approved for external use 29 of 94

DH-2751:2018
Australian Digital Health Agency

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

3.3.1.5 Content and Terminology

The tables below summarise My Health Record Specific Extension as applicable to

the Get PBS Items API.
Content Extension: Medication Generic Name

Table 16 – Content Extension: Medication Generic Name

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-generic-
URL: name

Name: Medication Generic Name

File Name: • StructureDefinition-medication-generic-name.xml

• StructureDefinition-medication-generic-name.json

This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

Content Extension: Medication Brand

Table 17 – Content Extension: Medication Brand

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-brand
URL:

Name: Medication Brand

File Name: • StructureDefinition-medication-brand.xml

• StructureDefinition-medication-brand.json

This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

Content Extension: Medication Form and Strength

Table 18 – Content Extension: Medication Form and Strength

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-form-and-
URL: strength

Name: Medication Form and Strength

File Name: • StructureDefinition-medication-form-and-strength.xml

• StructureDefinition-medication-form-and-strength.json

This is an extension on the Medication.product. More information can be found at Extension Registry
section.

Content Extension: Explanation of Benefit

30 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Table 19 - Content Extension: EOB Item Service

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/eob-item-service
URL:

Name: EOB Item Service

File Name: • StructureDefinition-eob-item-service.xml

• StructureDefinition-eob-item-service.json

This is an extension on the ExplanationOfBenefit.item.service. More information can be found at

Appendix E Extension Registry section.

Terminology: ExplanationOfBenefit Item Code

Table 20 - Terminology: ExplanationOfBenefit Item Code

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/ValueSet/eob-item-service
URL:

Name: ExplanationOfBenefit Item Code

File Name: • CodeSystem-eob-item-service.xml

• CodeSystem-eob-item-service.json
• ValueSet-eob-item-service.xml
• ValueSet-eob-item-service.json

Code Definition

Code Display Definition

MBS Medicare Benefit System Medicare Benefit System

PBS Pharmaceutical Benefit System Pharmaceutical Benefit System

The ValueSet is being Referenced from

http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/eob-item-service. More information can
be found at Appendix F Terminologies section.

3.3.1.6 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘ExplanationOfBenefit’ resources in either XML or JSON format.
Refer to "My Health Record FHIR Gateway - Sample Requests and Responses"
further details.
Refer to the “GetPBSItems” tab in the My Health Record – API Mapping document for
more details on the response mapping.

3.3.1.7 OperationOutcome Codes

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.

17 June 2019 Approved for external use 31 of 94

DH-2751:2018
Australian Digital Health Agency

Refer to the “Get PBS Items (GET)” section under “FHIR API Error Cases” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.3.2 Get MBS Items (GET)

3.3.2.1 Description

This API provides the ability to retrieve MBS details for the individual and returns a
bundle of ExplanationOfBenefit resources from the My Health Record system. A
maximum of 99 resources is returned in the response.

This API is accessible by both consumers and providers.

3.3.2.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘ExplanationOfBenefit’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.3.2.3 Versioning and History

• API Version: ‘v2.0.0’.

3.3.2.4 Request Message

Table 21 – Get MBS Items-Request Message

Resource URI [fqdn/fhir/v2.0.0]/ExplanationOfBenefit

32 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

Request
Parameters
(searchParam)

patientreference integer integer - - 1..1 Logical identifier of the

patient.
Additional validation is
performed on the IHI
corresponding to the
patientreference in the
URI to check if the
logged in user is
authorized to perform
any operation to the
IHI in context.

coverage.plan string string 3 3 1..1 Allowed value is ‘MBS’

created date ‘ge’yyyy- 12 12 0..1 From Date is a search

mm-dd criteria to select the
ExplanationOfBenefit
whose start date is
after the specific
period.
The date format must
be prefixed with the
value of ‘ge’ to
indicate the created
date must be greater-
than or equal to the
provided date.
Example: ge2016-05-
20
created date ‘le’yyyy- 12 12 0..1 To Date is a search
mm-dd criteria to select the
ExplanationOfBenefit
whose start date is
before the specific
period.
The date format must
be prefixed with the

17 June 2019 Approved for external use 33 of 94

DH-2751:2018
Australian Digital Health Agency

value of ‘le’ to indicate

the created date must
be less-than or equal
to the provided date.
Any future date
provided in the
request for ‘le’ will be
defaulted to server
current date.
Example: le2018-07-
14

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir
(to represent it as
JSON).

3.3.2.5 Content and Terminology

The tables below summarises My Health Record Specific Extension as applicable to

the Get MBS Items API.

Content Extension: Explanation of Benefit

Table 22 - Content Extension: EOB Item Service

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/eob-item-service
URL:

Name: EOB Item Service

File Name: • StructureDefinition-eob-item-service.xml

• StructureDefinition-eob-item-service.json

This is an extension on the ExplanationOfBenefit.item.service. More information can be found at

Appendix E Extension Registry section.

Terminology: ExplanationOfBenefit Item Code

Table 23 - Terminology: ExplanationOfBenefit Item Code

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/ValueSet/eob-item-service
URL:

Name: ExplanationOfBenefit Item Code

File Name: • CodeSystem-eob-item-service.xml

• CodeSystem-eob-item-service.json
• ValueSet-eob-item-service.xml
• ValueSet-eob-item-service.json

Code Definition

Code Display Definition

34 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

MBS Medicare Benefit System Medicare Benefit System

PBS Pharmaceutical Benefit System Pharmaceutical Benefit System

The ValueSet is being Referenced from

http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/eob-item-service . More information can
be found at Appendix F Terminologies section.

3.3.2.6 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘ExplanationOfBenefit ´ resources in either XML or JSON format.
Refer to "My Health Record FHIR Gateway - Sample Requests and Responses"
further details.
Refer to the “GetMBSItems” tab in the My Health Record – API Mapping document for
more details on the response mapping.

3.3.2.7 OperationOutcome Codes

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.

Refer to the “Get MBS Items (GET)” section under “FHIR API Error Cases” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
the All APIs exposed through My Health Record System.

3.4 Generic document services

There are two APIs classified under this group:

• Get Document (GET)

• Search Document List (GET)

3.4.1 Get Document (GET)

3.4.1.1 Description

This API provides the ability to retrieve a specific document for an individual from
the My Health Record system.
The API returns a base64binary of the CDA zip package as per the FHIR®
specification.
This API is accessible by both consumers and providers.

17 June 2019 Approved for external use 35 of 94

DH-2751:2018
Australian Digital Health Agency

As per My Health Record system policy, Medicare/DVA Benefits Report (TypeCode:

100.16644 & ClassCode: 100.16644) documents are not available for download by
consumers. Information from these documents can be accessed through the Get
MBS Items API.

3.4.1.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type): ‘Binary’

FHIR® based resource reference (Conformance.rest.resource.profile) is available
at:
• http://hl7.org/fhir/2016May/binary.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’).

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.4.1.3 Versioning and History

• API Version: ‘v2.0.0’.

3.4.1.4 Request Message

Table 24 – Get Document - Request Message

Resource URI [fqdn/fhir/v2.0.0]/Binary/[docID]

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from

36 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

which the app is

executed.

Request
Parameters
(searchParam)

patient integer integer - - 1..1 Logical identifier of the

patient.
Additional validation is
performed on the IHI
corresponding to the
logical identifier of the
patient in the URI to
check if the logged in
user is authorized to
perform any operation to
the IHI in context.

3.4.1.5 Response Message

The system will return ‘Binary’. The binary response which is formatted as
Base64Binary has an imposed upper limit of 7340032 Bytes (7 MB). A response
exceeding this size limit will result in an error message being thrown. Refer to
3.4.1.6 OperationOutcome Codes for more information.

Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses"
for further details.

Refer to the “GetDocument” tab in the My Health Record – API Mapping document for
more details on the response mapping.

3.4.1.6 OperationOutcome Codes

The API returns errors, warnings and information messages that provide detailed
information about the outcome of attempted system interactions. They are provided
as a direct system response, or component of one, where they provide information
about the outcome of the operation.
HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.

Refer to the “Get Document (GET)” section under “FHIR API Error Cases” tab of My
Health Record FHIR® Gateway – Error Mapping document to find the applicable
FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.4.2 Search Document List (GET)

3.4.2.1 Description

This API provides the ability to retrieve a list of document references for an
individual from the My Health Record system. The API returns the document
references for an individual by matching a class code provided as input. A
maximum of 99 DocumentReference resources is returned in the response.

This API is accessible by both consumers and providers.

17 June 2019 Approved for external use 37 of 94

DH-2751:2018
Australian Digital Health Agency

As per My Health Record system policy, Medicare/DVA Benefits Report (TypeCode:

100.16644 & ClassCode: 100.16644) documents are not available for download.
Correspondingly, the Search Document List API does not include documents of this
type in the list of returned document references.

3.4.2.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘DocumentReference’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/documentreference.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)
For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.4.2.3 Versioning and History

• API Version: ‘v2.0.0’.

3.4.2.4 Request Message

Table 25 – Get/Search Document List - Request Message

Resource URI [fqdn/fhir/v2.0.0]/DocumentReference

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Lengt Lengt
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

38 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

App-Version string - - - 1..1 This is the application version

as presented to the user. This
is mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

Request
Parameters
(searchParam)

patient intege integer - - 1..1 Logical identifier of the patient.

r Additional validation is
performed on the IHI
corresponding to the logical
identifier of the patient in the
URI to check if the logged in
user is authorized to perform
any operation to the IHI in
context.

class token string - - 0..* This code is to identify type of

the document.
Note: either ‘class’ or ‘type’ is
required in each
DocumentReference request.
Refer to the A.5 for more
details on Class Codes and
Type Codes.
The request message should
formed with the class =
ClassCode^^CodingSystem
e.g.: '100.16644^^NCTIS'

type token string - - 0..* Kind of document

Note: either ‘class’ or ‘type’ is
required in each
DocumentReference request.
Refer to the A.5 for more
details on Class Codes and
Type Codes.
The request message should
formed with the type =
TypeCode^^CodingSystem
e.g.: '100.16644^^NCTIS'

Optional Request Parameter

identifier string string - - 0..* Master Version Specific

Identifier
Note, CDA Document ID is
used in this search parameter
and search with identifier
cannot be combined with any
other optional search
parameters.

author refere string - - 0..* Who and/or what authored the

nce document

17 June 2019 Approved for external use 39 of 94

DH-2751:2018
Australian Digital Health Agency

created date ‘ge’yyyy 12 12 0..1 To Date is a search criteria to

-mm-dd select all documents whose
creation date is on or after the
specified period.
The date format must be
prefixed with the value of ‘ge’
to indicate the created date
must be greater-than or equal
to the provided date.
Example: ge2016-05-20

created date ‘le’yyyy 12 12 0..1 To Date is a search criteria to

-mm-dd select all documents whose
creation date is on or before
the specified period.
The date format must be
prefixed with the value of ‘le’
to indicate the created date
must be less-than or equal to
the provided date.
Any future date provided in
the request for ‘le’ will be
defaulted to server current
date.
Example: le2018-07-14

status token string - - 0..1 current (approved)|

superseded (deprecated)|
entered-in-error (deleted)

slotName string string - - 0..1 Any other custom slots

applicable to metadata as per
IHE standard. The list should
exclude corresponding IHE
slots values for: ‘identifier’,
’authenticator’, ‘author’,
‘custodian’, ‘format’, ’created’,
’status’. Refer to the section
‘Custom Slots for Search
Document List (GET)’ for
details.

slotValue string string - - 0..1 Value of the custom slot. This

can exist only if the custom
‘slotName’ is provided.

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

Note: All dates should be in UTC format.

3.4.2.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘DocumentReference’ resources in either XML or JSON format.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

40 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “SearchDocumentList” tab in the My Health Record – API Mapping

document for more details on the response mapping.

3.4.2.6 OperationOutcome Codes

The following table lists error, warning and information messages that provide
detailed information about the outcome of attempted system interactions. They are
provided as a direct system response, or component of one, where they provide
information about the outcome of the operation.

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.
Refer to the “Search Document List (GET)” section under “FHIR API Error Cases”
tab of My Health Record FHIR® Gateway – Error Mapping document to find the
applicable FHIR® API Error details.
Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5 Consumer documents

The following APIs are classified under this group:

• Personal Health Summary – Medications (GET)

• Personal Health Summary – Medications (POST)
• Personal Health Summary – Medications (PUT)
• Personal Health Summary – Medications (DELETE)
• Personal Health Summary – Allergies (GET)
• Personal Health Summary – Allergies (POST)
• Personal Health Summary – Allergies (PUT)
• Personal Health Summary – Allergies (DELETE)

3.5.1 Get Personal Health Summary - Medications (GET)

3.5.1.1 Description

This API provides the ability to retrieve Medications from an individual’s personal
health summary document from the My Health Record system.

This API is accessible by both consumers and providers.

3.5.1.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘MedicationStatement’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/medicationstatement.html
• http://hl7.org/fhir/2016May/operationoutcome.html

17 June 2019 Approved for external use 41 of 94

DH-2751:2018
Australian Digital Health Agency

This specification is intended to be used to describe an actual running instance of

software (Conformance.kind = ‘instance’)

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.5.1.3 Versioning and History

• API Version: ‘v2.0.0’.

3.5.1.4 Request Message

Table 26 – Get Personal Health Summary Medications - Request Message

Resource URI [fqdn/fhir/v2.0.0]/MedicationStatement

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

Request
Parameters
(searchParam)

patient integer integer - - 1..1 Logical identifier of the

patient.
Additional validation is
performed on the IHI

42 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

corresponding to the
logical identifier of the
patient in the URI to
check if the logged in
user is authorized to
perform any operation
to the IHI in context.

source._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir
(to represent it as
JSON).

3.5.1.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘MedicationStatement’ resources in either XML or JSON format.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API Mapping

document for more details on the response mapping.

3.5.1.6 OperationOutcome Codes

The API retuns error, warning and information messages that provide detailed
information about the outcome of attempted system interactions. They are provided
as a direct system response, or component of one, where they provide information
about the outcome of the operation.
HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body .

Refer to the “Get Personal Health Summary - Allergies (GET)” section under “FHIR
API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.
Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.2 Update Personal Health Summary - Medications (POST)

3.5.2.1 Description

This API provides the ability to create an individual’s MedicationStatement in the

Personal Health Summary document (type/class code = ‘100.16685’) stored in the
My Health Record system. Use this API if there is no Personal Summary Document
exits for the individual, or if the existing document doesn’t have any Medication
section.

17 June 2019 Approved for external use 43 of 94

DH-2751:2018
Australian Digital Health Agency

As consumers cannot be expected to safely provide coded medicines information,

such coding is stripped from uploaded MedicationStatement resources before being
persisted.

This API is accessible only by the consumer.

3.5.2.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘MedicationStatement’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/medicationstatement.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)
For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

The server only supports custom parameter ‘docId’ in conditional create

(Conformance.rest.resource.conditionalCreate = true).

The system internally creates a CDA of the Personal Health Summary document
based on the information received in the ‘MedicationStatement’ bundle or as individual
MedicationStatement resource.

3.5.2.3 Versioning and History

• API Version: ‘v2.0.0’.

3.5.2.4 Request Message

The table below summarises the request message when a Bundle containing
MedicationStatement resources is uploaded.

Table 27 – Update Personal Health Summary Medications - Request Message POST (Bundle)

Resource URI [fqdn/fhir/v2.0.0]

44 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method POST (create)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application version

as presented to the user. This
is mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

content-type string string 20 21 1..1 application/xml+fhir (or)

application/json+fhir
This is the MIME type of the
body of the request

Request
Parameters
(searchParam)

source._type string string 7 7 1..1 Allowed value is ‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

The request body should contain ‘Bundle’ of ‘MedicationStatement’ resources. The

‘Bundle.type’ in the Bundle resource should be ‘transaction’ and the ‘Bundle.entry’
should contain ‘request’ element with ‘request.method’ value as ‘POST’.

Note this base URI bundle also supports the upload of AllergyIntolerance resources,
however a single bundle request must not have these two resources together. The
server does not support such a combination of resources in the bundle transaction.
Instead, the request must exclusively be all MedicationStatement resources, or all
AllergyIntolerance resources.

Please refer to Appendix C.1.2 for the processing rules as applicable to the Bundle
POST of the MedicationStatement resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.
The table below summarises the request message when individual
MedicationStatement resource is uploaded.

Table 28 - Update Personal Health Summary Medications - Request Message POST (Individual)

Resource URI [fqdn/fhir/v2.0.0]/MedicationStatement

17 June 2019 Approved for external use 45 of 94

DH-2751:2018
Australian Digital Health Agency

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method POST (create)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

content-type string string 20 21 1..1 application/xml+fhir

(or)
application/json+fhir
This is the MIME
type of the body of the
request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

source._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir (to
represent it as XML) OR
application/json+fhir
(to represent it as
JSON).

The request body should contains individual ‘MedicationStatement’ resource.

Please refer to Appendix C.1.3 for the processing rules as applicable to the
individual POST of the MedicationStatement resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

46 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API Mapping

document for more details on the FHIR® element mapping.

3.5.2.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.

In case of Bundle POST, the system will return a Bundle resource with HTTP Status
Code 201 - Created if the request is successfully executed.

Refer to the “OperationOutcome” tab in the My Health Record – API Mapping document
for more details on the mapping.

3.5.2.6 OperationOutcome Codes

The API returns the HTTP error codes that are applicable to this service and will be
transmitted in the response header along with the OperationOutcome details in the
response body.

Refer to the “Update Personal Health Summary - Medications (POST)” section

under “FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error
Mapping document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.3 Update Personal Health Summary - Medications (PUT)

3.5.3.1 Description

This API provides the ability to update an individual’s MedicationStatement in the

Personal Health Summary document stored in the My Health Record system.

As consumers cannot be expected to safely provide coded medicines information,

such coding is stripped from uploaded MedicationStatement resources before being
persisted.

This API is accessible only by the consumer.

3.5.3.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘MedicationStatement’

FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

17 June 2019 Approved for external use 47 of 94

DH-2751:2018
Australian Digital Health Agency

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

The server doesn’t allow the client to create new identities on the server
(Conformance.rest.resource.updateCreate = false).

The server doesn’t support conditional update

(Conformance.rest.resource.conditionalUpdate = false).

The system internally updates the existing CDA of the Personal Health Summary
document based on the information received in the ‘MedicationStatement’ bundle or
as individual ‘MedicationStatement’ resource.

3.5.3.3 Versioning and History

• API Version: ‘v2.0.0’.

• FHIR® Version (Conformance.fhirVersion): ‘1.4.0’.
• Resource Instance Version (Conformance.rest.resource.versioning): ‘no-
version’. ‘VersionId’. meta-property is not supported (server) or used
(client).
• History (Conformance.rest.resource.readHistory): ‘false’. For API v2.0.0,
the server is not able to return past versions. ‘vRead’ interaction is not
supported.

3.5.3.4 Request Message

The table below summarises the update request message using a Bundle containing
MedicationStatement resources.

Table 29 - Update Personal Health Summary Medications - Request Message PUT (Bundle)

Resource URI [fqdn/fhir/v2.0.0]

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method PUT (update)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

48 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

content-type string string 20 21 1..1 application/xml+fhir

(or)
application/json+fhir
This is the MIME
type of the body of the
request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

source._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir (to
represent it as XML) OR
application/json+fhir
(to represent it as
JSON).

The request body should contain ‘Bundle’ of ‘MedicationStatement’ resources with

the document ID in the URI. The ‘Bundle.type’ in the Bundle resource should be
‘transaction’ and the ‘Bundle.entry’ should contain ‘request’ element with
‘request.method’ value as ‘PUT’ or ‘POST’.

Please refer to Appendix C.1.4 for the processing rules as applicable to the Bundle
PUT of the MedicationStatement resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

The table below summarises the update request message using individual
MedicationStatement resource.

Table 30 - Update Personal Health Summary Medications - Request Message PUT (Individual)

Resource URI [fqdn/fhir/v2.0.0]/MedicationStatement/[id]

Note: [id] is the unique logical-id (entry ID) of the MedicationStatment resource
in the Personal Health Summary CDA document.

17 June 2019 Approved for external use 49 of 94

DH-2751:2018
Australian Digital Health Agency

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method PUT (update)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

content-type string string 20 21 1..1 application/xml+fhir

(or)
application/json+fhir
This is the MIME
type of the body of the
request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

source._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir (to
represent it as XML) OR
application/json+fhir
(to represent it as
JSON).

The request body should contain individual ‘MedicationStatement’ resource with the
resource logical-id (‘id’) in the URI. The ID in the URI and the ID in the resource
should match.
Please refer to Appendix C.1.5 for the processing rules as applicable to the
individual PUT of the MedicationStatement resource.

50 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API

Mapping document for more details on the FHIR® element mapping.

3.5.3.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.
In case of Bundle PUT, based on whether the ‘request.method’ is set as ‘PUT’ or
‘POST’ for each of the resources in the request Bundle entry, the system will return
a Bundle resource with HTTP Status Code 200 - Ok for ‘PUT’ request with the
corresponding resource updated and 201 – Created for ‘POST’ request with the
corresponding resource being created.

In case of individual PUT, the system will return back the updated resource with the
same logical ID as in the request.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

In case of error, an OperationOutcome resource with details as applicable will be

returned.

Refer to the “OperationOutcome” tab in the My Health Record – API Mapping

document for more details on the response mapping.

3.5.3.6 OperationOutcome Codes

The API returns the HTTP error codes that are applicable to this service and will be
transmitted in the response header along with the OperationOutcome details in the
response body.

Refer to the “Update Personal Health Summary - Medications (PUT)” section under
“FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.4 Update Personal Health Summary - Medications (DELETE)

3.5.4.1 Description

This API provides the ability to delete an individual’s MedicationStatement in the

Personal Health Summary document stored in the My Health Record system.

This API is accessible only by the consumer.

3.5.4.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘MedicationStatement’
FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

• http://hl7.org/fhir/2016May/medicationstatement.html

17 June 2019 Approved for external use 51 of 94

DH-2751:2018
Australian Digital Health Agency

• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

The server executes only conditional delete and doesn’t support any other search
parameter than ‘patient’.

3.5.4.3 Versioning and History

• API Version: ‘v2.0.0’.

3.5.4.4 Request Message

Table 31 - Delete Personal Health Summary Medications - Request Message DELETE

Resource URI [fqdn/fhir/v2.0.0]/MedicationStatement/[id]

Note: [id] is the unique logical-Id (entry ID) of the MedicationStatement resource
in the Personal Health Summary CDA document.
[docId] is the unique Document ID of the Personal Health Summary CDA
document. This can be retrieved from Search Document List API.
Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method DELETE (delete)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

52 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Request
Parameters
(searchParam)

patient integer integer - - 1..1 Logical identifier of the

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

source._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir
(to represent it as
JSON).

Please refer to Appendix C.1.6 for the processing rules as applicable to the Delete
of the MedicationStatement resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

3.5.4.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.

The system will return HTTP Status Code 204 - No Content as the response upon
successful API call.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.
In case of error, an OperationOutcome resource with details as applicable will be
returned.

Refer to the “OperationOutcome” tab in the My Health Record – API Mapping

document for more details on the various error scenarios.

17 June 2019 Approved for external use 53 of 94

DH-2751:2018
Australian Digital Health Agency

3.5.4.6 OperationOutcome Codes

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.
Refer to the “Delete Personal Health Summary - Medication (DELETE)” section
under “FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error
Mapping document to find the applicable FHIR® API Error details.
Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.5 Get Personal Health Summary - Allergies (GET)

3.5.5.1 Description

This API provides the ability to retrieve allergies and adverse reactions information
from an individual’s Personal Health Summary document from the My Health
Record system.
This API is accessible by both consumers and providers.

3.5.5.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘AllergyIntolerance’

FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

3.5.5.3 Versioning and History

• API Version: ‘v2.0.0’.

54 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

3.5.5.4 Request Message

Table 32 – Get Personal Health Summary Allergies -Request Message

Resource URI [fqdn/fhir/v2.0.0]/ AllergyIntolerance

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Forma Min Max Cardinalit Remarks

Headers Type t Lengt Lengt y
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application version as

presented to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint) platform product

and version from which the app is
executed.

Request
Parameters
(searchParam)

patient integer integer - - 1..1 Logical identifier of the patient.

Additional validation is performed
on the IHI corresponding to the
logical identifier of the patient in
the URI to check if the logged in
user is authorized to perform any
operation to the IHI in context.

reporter._type string string 7 7 1..1 Allowed value as ‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to represent
it as XML) OR
application/json+fhir (to
represent it as JSON).

3.5.5.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘AllergyIntolerance’ resources in either XML or JSON format.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.
Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API
Mapping document for more details on the response mapping.

17 June 2019 Approved for external use 55 of 94

DH-2751:2018
Australian Digital Health Agency

3.5.5.6 OperationOutcome Codes

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.
Refer to the “Get Personal Health Summary - Allergies (GET)” section under “FHIR
API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.
Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.6 Update Personal Health Summary – Allergies (POST)

3.5.6.1 Description

This API provides the ability to create an individual’s allergies and adverse reactions
information in the Personal Health Summary document stored in the My Health
Record system. Use this API if there is no Personal Summary Document exits for
the individual, or if the existing document doesn’t have any Allergy section.

This API is accessible only by the consumer.

3.5.6.2 Message specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘AllergyIntolerance’

FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).

The server supports both XML and JSON transactions. The value can be
‘application/xml+fhir’ (to represent it as XML) Or ‘application/json+fhir’ (to
represent it as JSON). (Conformance.format = "xml" or "json”).
The server doesn’t support conditional create
(Conformance.rest.resource.conditionalCreate = false).
The system internally creates a CDA of the Personal Health Summary document
based on the information received in the ‘AllergyIntolerance’ bundle or as individual
‘AllergyIntolerance’ resource.

3.5.6.3 Versioning and History

• API Version: ‘v2.0.0’.

• FHIR® Version (Conformance.fhirVersion): ‘1.4.0’.

56 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

• Resource Instance Version (Conformance.rest.resource.versioning): ‘no-

version’. ‘VersionId’. meta-property is not supported (server) or used
(client).
• History (Conformance.rest.resource.readHistory): ‘false’. For API v2.0.0,
the server is not able to return past versions. ‘vRead’ interaction is not
supported.

3.5.6.4 Request Message

The table below summarises the request message when a bundle of

AllergyIntolerance resource is uploaded.

Table 33 – Update Personal Health Summary Allergies - Request Message POST

Resource URI [fqdn/fhir/v2.0.0]

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method POST(create)

(interaction)

Request Headers Type Format Min Max Cardinalit Remarks

Lengt Lengt y
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

content-type string string 20 21 1..1 application/xml+fhir (or)

application/json+fhir
This is the MIME type of
the body of the request

Request
Parameters
(searchParam)

reporter._type string string 7 7 1..1 Allowed value is ‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

The request body should contain ‘Bundle’ of ‘AllergyIntolerance’ resources. The

‘Bundle.type’ in the Bundle resource should be ‘transaction’ and the ‘Bundle.entry’
should contain ‘request’ element with ‘request.method’ value as ‘POST’.

17 June 2019 Approved for external use 57 of 94

DH-2751:2018
Australian Digital Health Agency

Note this base URI bundle also supports the upload of MedicationStatement
resources, however a single bundle request must not have these two resources
together. The server does not support such a combination of resources in the
bundle transaction. Instead, the request must exclusively be all
MedicationStatement resources, or all AllergyIntolerance resources.

Please refer to Appendix C.1.2 for the processing rules as applicable to the Bundle
POST of the AllergyIntolerance resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

The table below summarises the request message when individual

AllergyIntolerance resource is uploaded.
Table 34 - Update Personal Health Summary Allergies - Request Message POST (Individual)

Resource URI [fqdn/fhir/v2.0.0]/AllergyIntolerance

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method POST(create)

(interaction)

Request Headers Type Format Min Max Cardinality Remarks

Lengt Lengt
h h

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

content-type string string 20 21 1..1 application/xml+fhir (or)

application/json+fhir
This is the MIME type of
the body of the request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search parameter

UUID which should be used to
provide the latest
personal health summary
CDA document ID
retrieved from the
document reference API.

reporter._type string string 7 7 1..1 Allowed value is ‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR

58 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

application/json+fhir (to
represent it as JSON).

The request body should contain individual ‘AllergyIntolerance’ resource.

Please refer to Appendix C.1.3 for the processing rules as applicable to the
individual POST of the AllergyIntolerance resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API

Mapping document for more details on the FHIR® element mapping.

3.5.6.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.

In case of Bundle POST, the system will return a Bundle resource with HTTP Status
Code 201 - Created if the request is successfully executed.

In case of individual POST, the system will return back the newly created resource
with logical ID populated.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.
In case of error, an OperationOutcome resource with details as applicable will be
returned.
Refer to the “OperationOutcome” tab in the My Health Record – API Mapping
document for more details on the response mapping.

3.5.6.6 OperationOutcome Codes

The API returns the HTTP error codes that are applicable to this service and will be
transmitted in the response header along with the OperationOutcome details in the
response body.

Refer to the “Update Personal Health Summary – Allergies (POST)” section under
“FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.5.7 Update Personal Health Summary – Allergies (PUT)

3.5.7.1 Description

This API provides the ability to update an individual’s allergies and adverse
reactions information in the Personal Health Summary document stored in the My
Health Record system.
This API is accessible only by the consumer.

17 June 2019 Approved for external use 59 of 94

DH-2751:2018
Australian Digital Health Agency

3.5.7.2 Message Specification

Resource served on the REST interface (Conformance.rest.resource.type):

‘AllergyIntolerance’

FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

• http://hl7.org/fhir/2016May/allergyintolerance.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)
For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).
The server supports both XML and JSON transactions. The value can be
‘application/xml+fhir’ (to represent it as XML) Or ‘application/json+fhir’ (to
represent it as JSON). (Conformance.format = "xml" or "json”).

The server doesn’t allow the client to create new identities on the server
(Conformance.rest.resource.updateCreate = false)

The server doesn’t support conditional update

(Conformance.rest.resource.conditionalUpdate =false)

The system internally updates the existing CDA of the Personal Health Summary
document based on the information received in the ‘AllergyIntolerance’ bundle or as
individual ‘AllergyIntolerance’ resource.

3.5.7.3 Versioning and History

• API Version: ‘v2.0.0’.

3.5.7.4 Request Message

The table below summarises the update request message using a Bundle containing
AllergyIntolerance resources.

Table 35 - Update Personal Health Summary Allergies - Request Message PUT (Bundle)

Resource URI [fqdn/fhir/v2.0.0]

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method PUT(update)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

60 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

content-type string string 20 21 1..1 application/xml+fhir

(or)
application/json+fhir
This is the MIME
type of the body of the
request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

reporter._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir (to
represent it as XML) OR
application/json+fhir
(to represent it as
JSON).

The request body should contain ‘Bundle’ of ‘AllergyIntolerance’ resources with the
document ID in the URI. The ‘Bundle.type’ in the Bundle resource should be
‘transaction’ and the ‘Bundle.entry’ should contain ‘request’ element with
‘request.method’ value as ‘PUT’ or ‘POST’.

Please refer to Appendix C.1.4 for the processing rules as applicable to the Bundle
PUT of the AllergyIntolerance resource.

17 June 2019 Approved for external use 61 of 94

DH-2751:2018
Australian Digital Health Agency

Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

The table below summarises the update request message using individual
AllergyIntolerance resource.

Table 36 -Update Personal Health Summary Allergies - Request Message PUT (Individual)

Resource URI [fqdn/fhir/v2.0.0]/AllergyIntolerance/[id]

Note: [id] is the unique logical-id (entry ID) of AllergyIntolerance resource in the
Personal Health Summary CDA document.
Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method PUT(update)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented to
the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

content-type string string 20 21 1..1 application/xml+fhir

(or)
application/json+fhir
This is the MIME
type of the body of the
request

Request
Parameters
(searchParam)

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

reporter._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir (to
represent it as XML) OR
application/json+fhir

62 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

(to represent it as
JSON).

The request body should contain individual ‘AllergyIntolerance’ resource with the
resource logical-id (‘id’) in the URI. The ID in the URI and the ID in the resource
should match.
Please refer to Appendix C.1.5 for the processing rules as applicable to the
individual PUT of the AllergyIntolerance resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

Refer to the “GetPersonalHealthSummary” tab in the My Health Record – API

Mapping document for more details on the FHIR® element mapping.

3.5.7.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.

In case of Bundle PUT, based on whether the ‘request.method’ is set as ‘PUT’ or

‘POST’ for each of the resource in the request Bundle entry, the system will return a
Bundle resource with HTTP Status Code 200 - Ok for ‘PUT’ request with the
corresponding resource updated and 201 – Created for ‘POST’ request with the
corresponding resource being created.

In case of error, an OperationOutcome resource with details as applicable will be

returned.

Refer to the “OperationOutcome” tab in the My Health Record – API Mapping

document for more details on the response mapping.

3.5.7.6 OperationOutcome Codes

The API returns the HTTP error codes that are applicable to this service and will be
transmitted in the response header along with the OperationOutcome details in the
response body.
Refer to the “Update Personal Health Summary – Allergies (PUT)” section under
“FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

17 June 2019 Approved for external use 63 of 94

DH-2751:2018
Australian Digital Health Agency

3.5.8 Update Personal Health Summary - Allergies (DELETE)

3.5.8.1 Description

This API provides the ability to delete an individual’s allergies and adverse reactions
information in the Personal Health Summary document stored in the My Health
Record system.

This API is accessible only by the consumer.

3.5.8.2 Message specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘AllergyIntolerance’

FHIR® based resource reference (Conformance.rest.resource.profile) is available

at:

• http://hl7.org/fhir/2016May/allergyintolerance.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)
For API v2.0.0, the server does not accept unknown elements or extensions when
reading resources (Conformance.acceptUnknown = ‘no’).
The server executes only conditional delete and doesn’t support any other search
parameter than ‘patient’.

3.5.8.3 Versioning and History

• API Version: ‘v2.0.0’.

3.5.8.4 Request Message

Table 37 - Delete Personal Health Summary Allergies - Request Message DELETE

Resource URI [fqdn/fhir/v2.0.0]/AllergyIntolerance/[id]

Note: [id] is the unique logical-id (entry ID) of the AllergyIntolerance resource in
the Personal Health Summary CDA document.
[docId] is the unique Document ID of the Personal Health Summary CDA
document. This can be retrieved from Search Document List API.

64 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method PUT(update)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization String Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version String - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and
version from which the
app is executed.

Request
Parameters
(searchParam)

patient integer integer 1..1 Logical identifier of the

docId String OID or 1 64 1..1 Custom search

UUID parameter which
should be used to
provide the latest
personal health
summary CDA
document ID retrieved
from the document
reference API.

reporter._type string string 7 7 1..1 Allowed value is

‘Patient’

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir
(to represent it as
JSON).

17 June 2019 Approved for external use 65 of 94

DH-2751:2018
Australian Digital Health Agency

3.5.8.5 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘OperationOutcome’ resources in either XML or JSON format.

The system will return HTTP Status Code 204 – No Content as the response upon
successful API call.

Please refer to Appendix C.1.6 for the processing rules as applicable to the Delete
of the AllergyIntolerance resource.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.
In case of error scenarios, an OperationOutcome resource with details as applicable
will be returned.
Refer to the “OperationOutcome” tab in the My Health Record – API Mapping
document for more details on the various error scenarios.

3.5.8.6 OperationOutcome Codes

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.

Refer to the “Delete Personal Health Summary - Allergies (DELETE)” section under
“FHIR API Error Cases” tab of My Health Record FHIR® Gateway – Error Mapping
document to find the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.6 Clinical document services

There are two APIs classified under this group:

• Prescription and Dispense List (GET)

• Allergies List – from Shared Health Summary document (GET)

3.6.1 Prescription and Dispense List (GET)

3.6.1.1 Description

This API provides the ability to retrieve Prescription and Dispense information for an
individual from the My Health Record system and returns a bundle of
MedicationOrder or MedicationDispense resources. A maximum of 99 resources is
returned in the response.
This API is accessible by both consumer and provider.

3.6.1.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

MedicationDispense (for dispense), MedicationOrder (for prescription)

66 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

FHIR® based resource reference (Conformance.rest.resource.profile) is available at:

• http://hl7.org/fhir/2016May/medicationorder.html
• http://hl7.org/fhir/2016May/medicationdispense.html
• http://hl7.org/fhir/2016May/operationoutcome.html
This specification is intended to be used to describe an actual running instance of
software (Conformance.kind = ‘instance’)
For API v2.0.0, the application does not accept unknown elements or extensions
when reading resources (Conformance.acceptUnknown = ‘no’).
The server supports both XML and JSON transactions. The value can be
‘application/xml+fhir’ (to represent it as XML) Or ‘application/json+fhir’ (to
represent it as JSON). (Conformance.format = "xml" or "json”).

Server supports ‘_include’ value as “MedicationPrescription:prescription“ for

MedicationDispense API Call (Conformance.rest.resource.searchInclude =
‘MedicationPrescription:prescription’).

3.6.1.3 Versioning and History

• API Version: ‘v2.0.0’.

3.6.1.4 Request Message – MedicationOrder

Table 38 – Get Prescription and Dispense List (MedicationOrder) - Request Message

Resource URI [fqdn/fhir/v2.0.0]/MedicationOrder

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Data Format Min Max Cardinality Remarks

Headers Type Length Length

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application

version as presented
to the user. This is
mandatory.

Platform-Version String 0..1 Client (endpoint)

platform product and

17 June 2019 Approved for external use 67 of 94

DH-2751:2018
Australian Digital Health Agency

version from which the

app is executed.

Request
Parameters
(searchParam)

patient integer integer - - 1..1 Logical identifier of the

datewritten date ‘ge’yyyy- 12 12 0..1 From Date is a search

mm-dd criterion to select the
MedicationOrder
whose start date is
after the specific
period.
The date format must
be prefixed with the
value of ‘ge’ to
indicate the created
date must be greater-
than or equal to the
provided date.
Example: ge2016-05-
20
datewritten date ‘le’yyyy- 12 12 0..1 To Date is a search
mm-dd criterion to select the
MedicationOrder
whose start date is
before the specific
period.
The date format must
be prefixed with the
value of ‘le’ to indicate
the created date must
be less-than or equal
to the provided date.
Any future date
provided in the
request for ‘le’ will be
defaulted to server
current date.
Example: le2018-07-
14

_format MIME- MIME- 3 21 0..1 The suggested values

type type are
application/xml+fhir
(to represent it as
XML) OR
application/json+fhir

68 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

(to represent it as
JSON).

3.6.1.5 Content and Terminology

The tables below summarise My Health Record Specific Extension as applicable to

the Get Prescription and Dispense List API.

Content Extension: Medicationdispense Quantity Description

Table 39 – Content Extension: Medicationdispense Quantity Description

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medicationdispense-quantity-
URL: description

Name: Medicationdispense Quantity Description

File • StructureDefinition-medicationdispense-quantity-description.xml
Name: • StructureDefinition-medicationdispense-quantity-description.json

This is an extension on the MedicationDispense.quantity. More information can be found at Appendix E

Extension Registry section.

Content Extension: Medication Formula

Table 40 – Content Extension: Medication Formula

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-formula
URL:

Name: Medication Formula

File Name: • StructureDefinition-medication-formula.xml

• StructureDefinition-medication-formula.json
This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

Content Extension: Medication Additional Therapeutic Good Detail

Table 41 – Content Extension: Medication Additional Therapeutic Good Detail

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-additional-
URL: therapeutic-good-detail

Name: Medication Additional Therapeutic Good Detail

File Name: • StructureDefinition-medication-additional-therapeutic-good-detail.xml

• StructureDefinition-medication-additional-therapeutic-good-detail.json

This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

Content Extension: Medication Therapeutic Good Strength

Table 42 – Content Extension: Medication Therapeutic Good Strength

17 June 2019 Approved for external use 69 of 94

DH-2751:2018
Australian Digital Health Agency

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-
URL: therapeutic-good-strength

Name: Medication Therapeutic Good Strength

File Name: • StructureDefinition-medication-therapeutic-good-strength.xml

• StructureDefinition-medication-therapeutic-good-strength.json

This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

Content Extension: Medicationdispense Unique Prescription Number

Table 43 – Content Extension: MedicationDispense Unique Prescription Number

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medicationdispense-unique-
URL: prescription-number

Name: MedicationDispense Unique Prescription Number

File • StructureDefinition-medicationdispense-unique-prescription-number.xml
Name: • StructureDefinition-medicationdispense-unique-prescription-number.json

This is an extension on the MedicationDispense. More information can be found at Appendix E Extension
Registry section.

Content Extension: Medicationdispense Sequence Number

Table 44 – Content Extension: MedicationDispense Sequence Number

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medicationdispense-
URL: sequence-number

Name: MedicationDispense Sequence Number

File • StructureDefinition-medicationdispense-sequence-number.xml
Name: • StructureDefinition-medicationdispense-sequence-number.json

This is an extension on the MedicationDispense. More information can be found at Appendix E Extension
Registry section.

Content Extension: Medicationorder Quantity Description

Table 45 – Content Extension: MedicationOrder Quantity Description

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medicationorder-
URL: quantity-description

Name: MedicationOrder Quantity Description

File • StructureDefinition-medicationorder-quantity-description.xml
Name: • StructureDefinition-medicationorder-quantity-description.json

This is an extension on the MedicationOrder.dispenseRequest.quantity. More information can be found at

Appendix E Extension Registry section.

70 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Content Extension: Medication Generic Name

Table 46 – Content Extension: Medication Generic Name

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/medication-generic-
URL: name

Name: Medication Generic Name

File Name: • StructureDefinition-medication-generic-name.xml

• StructureDefinition-medication-generic-name.json

This is an extension on the Medication. More information can be found at Appendix E Extension Registry
section.

3.6.1.6 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘MedicationOrder’ and associated resources in either XML or JSON
format.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

3.6.1.7 Request Message for MedicationDispense

Table 47 – Get Prescription and Dispense List (MedicationDispense) - Request Message

Resource URI [fqdn/fhir/v2.0.0]/MedicationDispense

Refer to the “Action URI List” tab in the My Health Record – API Mapping document
for more details on the possible Action URIs.

HTTP Method GET

Request Data Format Min Max Cardinality Remarks

Headers Type Lengt Lengt
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application version

as presented to the user. This
is mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

Request
Parameters
(seachParam)

patient intege integer - - 1..1 Logical identifier of the patient.

r Additional validation is
performed on the IHI
corresponding to the logical
identifier of the patient in the
URI to check if the logged in

17 June 2019 Approved for external use 71 of 94

DH-2751:2018
Australian Digital Health Agency

user is authorized to perform

any operation to the IHI in
context.

whenhandedover date ‘ge’yyyy 12 12 0..1 From Date is a search criteria

-mm-dd to select the documents whose
start date is after the specific
period.
The date format must be
prefixed with the value of ‘ge’
to indicate the created date
must be greater-than or equal
to the provided date.
Example: ge2016-05-20
whenhandedover date ‘le’yyyy 12 12 0..1 To Date is a search criteria to
-mm-dd select the documents whose
start date is before the specific
period.
The date format must be
prefixed with the value of ‘le’
to indicate the created date
must be less-than or equal to
the provided date.
Any future date provided in
the request for ‘le’ will be
defaulted to server current
date.
Example: le2018-07-14

_include string string 36 36 0..1 Include the prescription

reference in the response.
Allowed Parameter Value:
MedicationDispense:authorizin
gPrescription

_format MIME- MIME- 3 21 0..1 The suggested values are

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

Please refer to Appendix B.1 API Error for all common error applicable to the Get
Prescription and Dispense List API.

3.6.1.8 Response Message

Based on the MIME header (Accept) or ‘_format’ request parameter, the system will
return ‘Bundle’ of ‘MedicationDispense’ and associated resources in either XML or
JSON format.
Refer to the "My Health Record FHIR Gateway - Sample Requests and Responses" for further
details.

3.6.1.9 OperationOutcome Codes

The API returns error, warning and information messages that provide detailed
information about the outcome of attempted system interactions. They are provided

72 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

as a direct system response, or component of one, where they provide information

about the outcome of the operation.

HTTP error codes that are applicable to this service and will be transmitted in the
response header along with the OperationOutcome details in the response body.

Refer to the “Prescription and Dispense List (GET)” section under “FHIR API Error
Cases” tab of My Health Record FHIR® Gateway – Error Mapping document to find
the applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

3.6.2 Get Allergies List (SHS) (GET)

3.6.2.1 Description

This API provides the ability to retrieve an individual’s allergies and adverse
reactions information and returns a bundle of AllergyIntolerance resources from the
most recent Shared Health Summary document stored in the consumer’s My Health
Record. A maximum of 99 resources is returned in the response.

This API is accessible by both consumers and providers.

3.6.2.2 Message Specifications

Resource served on the REST interface (Conformance.rest.resource.type):

‘AllergyIntolerance’
FHIR® based resource reference (Conformance.rest.resource.profile):

3.6.2.3 Versioning and History

• API Version: ‘v2.0.0’.

17 June 2019 Approved for external use 73 of 94

DH-2751:2018
Australian Digital Health Agency

3.6.2.4 Request Message

Table 48 – Get Allergies List (SHS) - Request Message

Resource URI [fqdn/fhir/v2.0.0]/AllergyIntolerance

Refer to the “Action URI List” tab in the My Health Record – API Mapping
document for more details on the possible Action URIs.

HTTP Method GET (read)

(interaction)

Request Headers Data Format Min Max Cardinalit Remarks

Type Lengt Lengt y
h h

Authorization string Bearer 15 54 1..1 OAuth Token

App-Id UUID UUID 36 36 1..1 Application ID

App-Version string - - - 1..1 This is the application version

as presented to the user.
This is mandatory.

Platform-Version String 0..1 Client (endpoint) platform

product and version from
which the app is executed.

Request
Parameters
(searchParam)

patient intege integer - - 1..1 Logical identifier of the

r patient.
Additional validation is
performed on the IHI
corresponding to the logical
identifier of the patient in the
URI to check if the logged in
user is authorized to perform
any operation to the IHI in
context.

reporter._type string string 12 12 1..1 Allowed value is

“Practitioner”.

_format MIME- MIME- 3 21 0..1 The suggested values can be

type type application/xml+fhir (to
represent it as XML) OR
application/json+fhir (to
represent it as JSON).

74 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

3.6.2.5 Content and Terminology

The tables below summarise My Health Record Specific Extension as applicable to

the Get Allergies List API.

Content Extension: AllergyIntolerance Type

Table 49 - Content Extension: au-allergyintolerance-detailed-type

Defining http://hl7.org.au/fhir/StructureDefinition/au-allergyintolerance-detailed-type
URL:

Name: Australian AllergyIntolerance Detailed Type Extension

File Name: • StructureDefinition-au-allergyintolerance-detailed-type.xml

• StructureDefinition-au-allergyintolerance-detailed-type.json

This is an extension on the AllergyIntolerance resource. More information can be found at Appendix E
Extension Registry section.

The table below shows how the three elements of AllergyIntolerance resource will
be populated.

Table 50 - AllergyIntolerance Type and Category Mapping

SL No SNOMED CT Preferred AllergyIntolerance.type AllergyIntolerance.categor

Code Term Mapping y Mapping

1 401207004 Medication intolerance medication

side-effect

2 235719002 Food intolerance food

intolerance

3 90092004 Hypersensitivi allergy N/A

ty reaction
type II

4 12263007 Hypersensitivi allergy N/A

ty reaction
type I

5 419076005 Allergic allergy N/A

reaction

6 609406000 Non-allergic N/A N/A

reaction

7 28031001 Hypersensitivi allergy N/A

ty reaction
type IV

8 83699005 Hypersensitivi allergy N/A

ty reaction
type III

9 281647001 Adverse N/A N/A

reaction

10 404204005 Drug N/A medication

interaction
with drug

17 June 2019 Approved for external use 75 of 94

DH-2751:2018
Australian Digital Health Agency

SL No SNOMED CT Preferred AllergyIntolerance.type AllergyIntolerance.categor

Code Term Mapping y Mapping

11 95907004 Drug N/A medication

interaction
with food

12 79899007 Drug N/A medication

interaction

13 75478009 Toxicity intolerance N/A

3.6.2.6 Response Message

Refer to Appendix B.1 API Error for a full list of errors applicable to the Get Allergies
List API.

3.6.2.7 OperationOutcome Codes

The API returns the HTTP error codes that are applicable to this service and will be
transmitted in the response header along with the OperationOutcome details in the
response body.

Refer to the “Get Allergies List (SHS) (GET)” section under “FHIR API Error Cases”
tab of My Health Record FHIR® Gateway – Error Mapping document to find the
applicable FHIR® API Error details.

Please refer to Appendix B.1 API Error for a full list of common errors applicable to
all the APIs exposed through My Health Record System.

76 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Appendix A Common
A.1 API List
The following table provides a complete list of the My Health Record Mobility APIs.

Table 51 - My Health Record Mobility APIs

Service Service Description Type

Individual Initial Authentication Username and password check with Login

myGov

Get or Refresh Individual Obtain access token for subsequent Login

Access Token requests for individual access

Initial Provider Authentication Obtain access token for subsequent Login

(JWT) requests for provider access

Get Record List Retrieve list of records the user is Read

permitted to access

Get Patient Details Retrieve individual’s demographics Read

details

Gain Access to Patient Gain Access to Patient record Write

Get PBS Items Retrieve PBS items for a record Read

Get MBS Items Retrieve MBS items for a record Read

v2.0.0 API List

Get Prescription and Dispense Retrieve medications list for a Read

List record from Prescribe and Dispense
CDAs

Get Allergies List Retrieve allergies and adverse Read

reactions from Shared Health
Summary Data

Get Personal Health Summary - Retrieve Personal Health Summary Read

Medications CDA Medication Data

Get Personal Health Summary - Retrieve Personal Health Summary Read

Allergies CDA Allergies Data

Update Personal Health Update Personal Health Summary Write

Summary - Medications CDA

Update Personal Health Update Personal Health Summary Write

Summary - Allergies CDA

Get / Search Document List Retrieve document list and Read

metadata. May be filtered based on
parameters (e.g. document type)

Get Document Retrieve all content for a CDA Read

document

17 June 2019 Approved for external use 77 of 94

DH-2751:2018
Australian Digital Health Agency

A.2 Representative Type

The following table provides an explanation of representative types in the My Health
Record system.

Table 52 - My Health Record Representative Types

Representative Type Description

self Self-access

Authorised Representative

Under 18 – Parental Responsibility An Authorised Representative is someone who can apply for and
Under 18 – Legal Authority manage a My Health Record on behalf of another person.

Under 18 – Otherwise Appropriate For the purposes of the My Health Record system someone can
Person be an Authorised Representative if they:

18 and Over – Otherwise Appropriate have parental responsibility for a person under 18; or
Person have legal authority to act on behalf of a person who is at least
18 and Over – Legal Authority 18 and who is not capable of making his or her own decisions.
If there is no one with parental responsibility or legal authority,
a person who is otherwise appropriate to act on behalf of the
individual can be an Authorised Representative. An individual
can have more than one Authorised Representative.

Nominated Representative

Full Access Nominated Representative A Full Access Nominated Representative is able to perform all
the functions of an Authorised Representative in respect of an
individual’s My Health Record with the exception of cancelling
the record, viewing the Access history, and viewing or adding
other representatives.
A Full Access Nominated Representative must verify their
identity to the System Operator.

General Access Nom Representative The general access setting allows a Nominated Representative
to access the individual’s My Health Record and view those
documents classified as general access.

Restricted Access Nom Representative The general access setting allows a Nominated Representative
to access the individual’s My Health Record and view those
documents classified as restricted access.

A.3 Display Name of CodeableConcept

A one-to-one mapping for codeSystemName, displayName and codeSystemVersion
has been defined between CDA code and FHIR® CodeableConcept. However, where
the My Health Record system returns multiple items in a consolidated format (e.g.:
FHIR® bundle), these values may differ from those provided in the source CDA.

When returning a FHIR® bundle referencing the national terminologies (SNOMED

CT-AU or Australian PBS/MBS Codes etc.), the My Health Record system will
attempt to provide a displayName obtained by referencing the default version of
the supported terminology loaded into the My Health Record terminology service.
Where a code, codeSystem or codeSystemVersion is unknown to this service, the
My Health Record system will return the originalText if available, and the
displayName of the source CDA’s coded concept.

78 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

The code and codeSystem values will always match those provided in the source
CDA.

A.4 Custom Slots for Search Document List (GET)

Table 69 – Custom Slots for Search Document List (GET)

Parameter Name Attribute Example

$XDSDocumentEntryPracti XDSDocumentEntry.
'7562-1^^ANZSIC'
ceSettingCode practiceSettingCode

Lower value of
$XDSDocumentEntryServi 2016-05-30T17:20:00Z
XDSDocumentEntry.
ceStartTimeFrom
serviceStartTime

$XDSDocumentEntryServi Upper value of XDSDocumentEntry. 2016-05-30T17:20:00Z

ceStartTimeTo serviceStartTime

$XDSDocumentEntryServi Lower value of XDSDocumentEntry. 2016-05-30T17:20:00Z

ceStopTimeFrom serviceStopTime

$XDSDocumentEntryServi Upper value of XDSDocumentEntry. 2016-05-30T17:20:00Z

ceStopTimeTo serviceStopTime

$XDSDocumentEntryHealt XDSDocumentEntry.
'7562^^ANZSIC'
hcareFacilityTypeCode healthcareFacilityTypeCode

$XDSDocumentEntryForm '1.2.36.1.2001.1006.1.16644.6^
XDSDocumentEntry. formatCode
atCode ^PCEHR_FormatCodes'

$XDSDocumentEntryUniqu
XDSDocumentEntry. uniqueId '1.2.13.1.3998.2548746'
eId

A.5 Type Codes and Class Codes

The table below lists the class code and type code as supported by the My Health
Record system at present.

Table 53 - Type Codes and Class Codes

Coding System ClassCode TypeCode Display Name

LOINC1 60591-5 60591-5 Shared Health Summary

LOINC 57133-1 57133-1 e-Referral

LOINC 51852-2 51852-2 Specialist Letter

LOINC 18842-5 18842-5 Discharge Summary

LOINC 34133-9 34133-9 Event Summary

NCTIS 100.16650 100.16650 Pharmaceutical Benefits Report

NCTIS 100.17042 100.17042 Australian Immunisation Register

NCTIS 100.16659 100.16659 Australian Childhood Immunisation

NCTIS 100.16644 100.16644 Medicare/DVA Benefits Report

NCTIS 100.16671 100.16671 Australian Organ Donor Register

17 June 2019 Approved for external use 79 of 94

DH-2751:2018
Australian Digital Health Agency

Coding System ClassCode TypeCode Display Name

NCTIS Data 100.16681 100.16681 Personal Health Note

Components

NCTIS Data 100.16685 100.16685 Personal Health Summary

Components

NCTIS Data 100.16696 100.16696 Advance Care Directive Custodian

Components Record

NCTIS Data 100.16764 100.16764 eHealth Prescription Record

Components

NCTIS Data 100.16765 100.16765 eHealth Dispense Record

Components

NCTIS Data 100.16957 100.16957 Diagnostic Imaging Report

Components

NCTIS Data 100.32001 100.32001 Pathology Report

Components

NCTIS Data 100.16870 100.16870 Consumer Entered Measurements

Components

NCTIS Data 100.16919 100.16919 Child Parent Questionnaire

Components

NCTIS Data 100.16975 100.16998 Advance Care Planning Document

Components

NCTIS Data 100.16812 100.16812 Consumer Entered Achievements

Components

LOINC 56445-0 56445-0 Pharmacist Curated Medicines List

Note: The list above may not contain all documents. Any additions to a new Type
Code or Class Code which are not listed above, will be included separately.
‘Australian Childhood Immunisation Register’ has been super superseded by
‘Australian Immunisation Register’

A.6 Type and Category Mapping

The table below shows how the three elements of AllergyIntolerance resource will
be populated.

Table 54 - AllergyIntolerance Type and Category Mapping

SL No SNOMED Preferred AllergyIntolerance.type AllergyIntolerance.category

CT Code Term Mapping Mapping

1 401207004 Medication intolerance medication

side-effect

2 235719002 Food intolerance food

intolerance

3 90092004 Hypersensitivity allergy N/A

reaction type II

4 12263007 Hypersensitivity allergy N/A

reaction type I

80 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

SL No SNOMED Preferred AllergyIntolerance.type AllergyIntolerance.category

CT Code Term Mapping Mapping

5 419076005 Allergic allergy N/A

reaction

6 609406000 Non-allergic N/A N/A

reaction

7 28031001 Hypersensitivity allergy N/A

reaction type
IV

8 83699005 Hypersensitivity allergy N/A

reaction type
III

9 281647001 Adverse N/A N/A

reaction

10 404204005 Drug N/A medication

interaction with
drug

11 95907004 Drug N/A medication

interaction with
food

12 79899007 Drug N/A medication

interaction

13 75478009 Toxicity intolerance N/A

A.7 Event Notification

The table below lists the different notifications that the API will trigger.

Table 55 – Event Notification

Business Event Name API Trigger Message (EventNotificationText)

(APINotificationType)

UploadDocumentMetadata MBS MBS uploaded

PBS PBS uploaded

PrescriptionRecord Prescription record uploaded

DispenseRecord Dispense record uploaded

UploadDocument PrescriptionRecord Prescription record uploaded

DispenseRecord Dispense record uploaded

PHS PHS uploaded

SHS SHS uploaded

17 June 2019 Approved for external use 81 of 94

DH-2751:2018
Australian Digital Health Agency

Appendix B Referenced Artefacts

B.1 API Error Handling
The system returns an OperationOutcome resource in error conditions.

For search error conditions, the server returns a Bundle with including an
OperationOutcome in the search set that contains information and warnings about
the search process. The OperationOutcome is included in the search results as an
entry with search mode = “outcome”. However, the server returns an
OperationOutcome only with error/exception details for search failure occurred due
to system or backend system exception.
Refer to the “Common System Error Applicable to ALL APIs” section in My Health
Record FHIR® Gateway – Error Mapping document to find the applicable FHIR® API
Error details.

B.2 FHIR® Mapping

Refer to the My Health Record FHIR Gateway – Data Mapping document to find the
applicable FHIR® API mapping information.

Note: The samples provided in the document are only for reference purposes. The
ValueSet and StructureDefinition details as mentioned in the document are not
available in the server as FHIR® resources. The URI used in the StructureDefinition
and ValueSet is temporary and may get changed in future releases.

82 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Appendix C Personal Health Summary

C.1 Processing Rules: Personal Health Summary
Document
This section talks about the processing rules that should be taken into consideration
when API call with POST and PUT interaction is performed.

Identifier Types
The section below describes server implementation and handling of Identifiers for
Personal Health Summary document:
• Logical identifier (‘id’): In personal health summary
MedicationStatement and AllergyIntolerance resources, the logical identifier
is mapped to the entry ID (‘entry/substanceAdministration/id’) of Personal
Health Summary Document.
• Document ID (‘docId’): This is a custom parameter in the system to
represent the Personal Health Summary CDA Document ID. Server expects
that the calling system should use Search Document List API to retrieve the
latest Personal Health Summary document and use the ID for making
respective calls in MedicationStatement or AllergyIntolerance API
(POST/PUT/DELETE interactions).
• Business identifier (‘identifier’): My Health Record system doesn’t
support ‘identifier’ for MedicationStatement or AllergyIntolerance API.

Processing Rules for POST Interaction (Bundle)

• Use this if there is no Personal Health Summary Document Exists for the
Patient, or the existing document doesn’t have the respective section.
Example, if the request is for MedicationStatement Bundle then make sure
the existing CDA doesn’t have any Medication section.
• The POST request SHALL NOT contain combination of POST and
GET/PUT/DELETE entries (‘request.method’) in the bundle. System
validates ‘request.method’ with the API interaction (POST) to ensure that
the valid request is received to execute POST interaction. Any mismatch
SHALL result an OperationOutcome.
• The POST request SHALL NOT contain a combination of AllergyIntolerance
and MedicationStatement resources. Instead, the bundle must exclusively
be all MedicationStatement resources, or all AllergyIntolerance resources.
• Each entry in the Bundle SHALL have a fullUrl, server may ignore the value
of the fullURL.
• The request Bundle SHALL NOT have any ID.
• Entries in the request Bundle SHALL NOT have any ID. If any ID found, the
request should be rejected with 400 error.
• The value of ‘request.url’ could be same as ‘resourceType’ found in the
bundle.

17 June 2019 Approved for external use 83 of 94

DH-2751:2018
Australian Digital Health Agency

• If any error occurs during processing any of the resources in the Bundle,
entire transaction will be rolled back as failure and an OperationOutcome
resource will be returned back.
• The request body SHALL NOT contain any ‘identifier’. If provided, system
will ignore that value.
• A new CDA will be created based on the content received in the Bundle.

Processing Rules for POST Interaction (Individual)

• The request URI SHALL contain the custom parameter ‘docId’. The value of
the ‘docId’ should be retrieved from Search Document List API while calling
this API.
• The request body SHALL NOT contain any ‘id’ element. If an ‘id’ element is
provided, the server SHALL respond with a HTTP 400 error code, and
SHOULD provide an OperationOutcome identifying the issue.
• The request body SHALL NOT contain any ‘identifier’. If provided, system
will ignore that.
• A new CDA will be created based on the content received in the individual
resource (MedicatinStatement/AllergyIntolerrance).

Processing Rules for PUT Interaction (Bundle)

• The request Bundle SHALL have the ID. This ID represents the Personal
Health Summary Document ID and should match with the ID provided in
the URI.
• The value of ‘request.url’ could be same as ‘resourceType’ found in the
bundle.
• Each entry SHALL have a fullUrl, server may ignore the value of the
fullURL.
• Entries in PUT request may contain GET, PUT, POST and DELETE
‘request.method’ combinations.
• The POST request SHALL NOT contain a combination of AllergyIntolerance
and MedicationStatement resources. Instead, the bundle must exclusively
be all MedicationStatement resources, or all AllergyIntolerance resources.
• Entries in the request Bundle SHALL have ‘id’ if the ‘request.method’ =
“PUT” or “GET” or “DELETE”.
• If the ‘request.method’ is a 'PUT' or 'POST', then the entry SHALL contain a
resource that becomes the body of the HTTP interaction.
• The processing rule is as follows when multiple combinations of
‘request.method’ is found inside the bundle:
o Process any DELETE interactions
o Process any POST interactions
o Process any PUT interactions
o Process any GET interactions
• The system expects the Bundle should contain all the entries based on
which the CDA document will be created. Any entry missing in the request
Bundle will be removed from the updated version of the CDA document. If

84 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

an empty Bundle is submitted, system will remove the corresponding

section from the CDA completely.
• If the “request.method = PUT”, the corresponding entry in the Bundle
should have a valid logical ID associated with the resource. Missing logical
ID in this case will result an OperationOutcome. The same is applicable for
“GET” ‘request.method’.
• If any error occurs during processing any of the resources in the Bundle,
entire transaction SHALL be rolled back as failure and an
OperationOutcome resource SHALL be returned back.
• The request body SHALL NOT contain any ‘identifier’. If provided, system
will ignore that value.
• System doesn’t support empty Bundle and Bundle containing only DELETE
entries.

Processing Rules for PUT Interaction (Individual)

• Use this when there is already a Personal Health Summary CDA available
for the Patient.
• The request URI SHALL contain the custom parameter ‘docId’. The value of
the ‘docId’ should be retrieved from Search Document List API while calling
this API.
• The request SHALL have the ID. This ID represents the individual entry ID
in the Personal Health Summary CDA Document. If ‘id’ is missing from the
request body, system will return back OperationOutcome.
• The request body SHALL NOT contain any ‘identifier’. If provided, system
will ignore that value.
• A new CDA will be created based on the content received in the individual
resource (MedicationStatement/AllergyIntolerance).

Processing Rules for Delete Interaction (Individual)

• The request URI SHALL contain an ‘id’ element. The ‘id’ should correspond
to an entry ID in the CDA. If not found, an OperationOutcome will be
returned back.
• The request URI SHALL contain the custom parameter ‘docId’. The value of
the ‘docId’ should be retrieved from Search Document List API while calling
this API.
• ‘patient’ parameter is required in the request URL.
• If there is no PHS CDA exists, an OperationOutcome will be returned to
inform that no document exists.
• Once the request is processed successfully, the response will be retuned
back with HTTP 204 - No Content code.
• The server executes only conditional delete and doesn’t support any other
search parameter than ‘patient’.
• A new CDA will be created after removing the entry corresponding to the
entry ID as received in the DELETE request. If there is only one entry found
in the existing CDA and a valid DELETE request is received, then the CDA
will be removed.

17 June 2019 Approved for external use 85 of 94

DH-2751:2018
Australian Digital Health Agency

Appendix D Patient Search by

Provider – Alternative Search Criteria
D.1 Search Parameter
If the IHI number is not available for the patient, the provider can search the
patient with valid information for all the fields as mentioned below:

Table 56 - Patient Search Parameter

Request Data Format Min Max Cardinality Remarks

Parameters Type Length Length
(searchParam)

coverageId string string/token 16 - 1..1 The values can be

any of the
following:
• Medicare Card
Number (11
digits)
• DVA File Number

birthdate date yyyy-mm-dd - - 1..1 Date of Birth of the

patient. Part of
‘subject’ in the
Parameter

gender token code 4 10 1..1 Gender value as

token. Part of
‘subject’ in the
Parameter
The allowed values
are “male”,
“female”, “other”,
and “unknown”.

family string string 1 40 1..1 Family Name of the

patient. Part of
‘subject’ in the
Parameter. Not
case-sensitive.

given string string 1 40 0..1 Given Name of the

patient. Part of
‘subject’ in the
Parameter. Not
case-sensitive.

The above list of search parameters is applicable only when the provider is
searching a patient with demographic details. System will ignore them if used in a
consumer Patient API.

D.2 Identifier System URL

The table below shows the URL to be used for identifier as the search criteria.

86 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Table 57 - Identifier System URL

# Identifier System Remarks Search

Type Parameter
Used

1 Medicare http://ns.electronichealth.net.au/id/hi/mc Value for coverageId

Card Identifier.system
Number

The value should

include IRN
number

2 DVA File http://ns.electronichealth.net.au/id/hi/dva Value for coverageId

Number Identifier.system

3 IHI http://ns.electronichealth.net.au/id/hi/ihi/1.0 IHI is the default Identifier

identifier.
When searched
with IHI, no other
search
parameters as
mentioned in
section 3.2.2.4
are required.

Please note, system doesn’t support all the types of Identifiers as mentioned in the
Australian Patient Identifiers portal. System only supports the three Business
Identifiers for the patient resource as shown in the table above.

D.3 Access Policy for Providers

My Health Record’s system policy enforces the provider to gain access to the
patient’s record before they can view any details associated with the patient. This
applies while viewing demographic details of the patient as well.

Access to the patient’s record can be achieved by calling the custom FHIR®
operation “$access” on Patient API.

D.4 Provider Access: Status and Types

The below table provides the summary of Access Code status as returned by the
Patient API when searched by provider. The value indicates what request parameter
is required to perform $access operation using Patient API.
Content Extension: Resource Access Status

Table 58 - Content Extension: Resource Access Status

Defining http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/patient-access-criteria
URL:

Name: Resource Access Status Type

File • StructureDefinition-patient-access-criteria.xml
Name: • StructureDefinition-patient-access-criteria.json

17 June 2019 Approved for external use 87 of 94

DH-2751:2018
Australian Digital Health Agency

This is an extension on the Bundle.search.mode. More information can be found at Appendix E

Extension Registry section.

Terminology: Resource Access Status

Table 59 - Terminology: Resource Access Status

Defining URL: http://ns.electronichealth.net.au/fhir/v2.0.0/ValueSet/patient-access-criteria

Name: Patient Access Criteria Type Code

File Name: • ValueSet-patient-access-criteria.xml

• ValueSet-patient-access-criteria.json
• CodeSystem-patient-access-criteria.json
• CodeSystem-patient-access-criteria.xml

Code Definition

WithCode Access can be obtained by invoking $access operation on Patient API with
providing an ‘accessType’ in the request Parameter.

WithoutCode Access can be obtained by invoking $access operation on Patient API. This
interaction doesn’t require ‘accessType’ Parameter.

AccessGranted Access is granted and can patient details can be obtained without invoking
$access operation on Patient API.

The ValueSet is being Referenced from http://ns.electronichealth.net.au/fhir/v2.0.0/StructureDefinition/patient-

access-criteria and from the Out Parameter when $access operation is performed. More information can be found
at Appendix F Terminologies section.

88 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Appendix E Extension Registry

All extensions are defined under http://hl7.org/fhir/StructureDefinition/ . Additional
extensions can be found on the My Health Record FHIR Registry at
http://ns.electronichealth.net.au/

Table 60 - Extensions

ID Description Cardinality Type Defining URL

Resource Patient

patient- A set of codes which 0..1 code http://ns.electronichealth.net.au/f

access- specifies the Patient hir/v2.0.0/ValueSet/patient-
criteria Access Criteria. access-criteria

Resource RelatedPerson
relationship- My Health Record 0..1 CodeableCon http://ns.electronichealth.net.au/f
type System extension to cept hir/v2.0.0/StructureDefinition/rela
include relationship tionship-type
type of the patient
and the related
person.

Resource Medication
medication- An item of information 0..1 string http://ns.electronichealth.net.au/f
generic- about a therapeutic hir/v2.0.0/StructureDefinition/med
name good. ication-generic-name
medication- The brand of the 0..1 string http://ns.electronichealth.net.au/f
brand pharmaceutical item hir/v2.0.0/StructureDefinition/med
supplied. ication-brand

medication- My Health Record 0..1 string http://ns.electronichealth.net.au/f

additional- System extension to hir/v2.0.0/StructureDefinition/med
therapeutic- include medication ication-additional-therapeutic-
good-detail
good-detail additional therapeutic
good detail.

medication- Medication Form and 0..1 string http://ns.electronichealth.net.au/f

form-and- Strength hir/v2.0.0/StructureDefinition/med
strength ication-form-and-strength

medication- Medication Formula 0..1 string http://ns.electronichealth.net.au/f

formula hir/v2.0.0/StructureDefinition/med
ication-formula

medication- Medication 0..1 string http://ns.electronichealth.net.au/f

therapeutic- Therapeutic Good hir/v2.0.0/StructureDefinition/med
good- Strength ication-therapeutic-good-strength
strength

Resource MedicationOrder
medicationor Free text description 0..1 string http://ns.electronichealth.net.au/f
der- of the amount which hir/v2.0.0/StructureDefinition/med
quantity- may consist of the icationorder-quantity-description
description quantity and dose
unit.

17 June 2019 Approved for external use 89 of 94

DH-2751:2018
Australian Digital Health Agency

Resource MedicationDispense
medicationdi Free text description 0..1 string http://ns.electronichealth.net.au/f
spense- of the amount which hir/v2.0.0/StructureDefinition/med
quantity- may consist of the icationdispense-quantity-
description
description quantity and dose
unit.

medicationdi A numeric value that 0..1 string http://ns.electronichealth.net.au/f

spense- represents the hir/v2.0.0/StructureDefinition/med
sequence- dispense number or icationdispense-sequence-number
number sequence number that
has been reached for
a therapeutic good
prescribed with
repeats. This count
includes the first
dispense. It has the
value 1 when there
are no repeats.

medicationdi A system identifier of 0..1 string http://ns.electronichealth.net.au/f

spense- additional hir/v2.0.0/StructureDefinition/Med
unique- administrative icationDispense-unique-
information relevant prescription-number
prescription-
to this medication
number action.

Resource AllergyIntolernace
au- A set of codes which 0..1 Coding http://ns.electronichealth.net.au/f
allergyintoler specifies the hir/v2.0.0/StructureDefinition/au-
ance- AllergyIntolerance allergyintolerance-detailed-type
detailed-type type for the patient.

Resource ExplanationOfBenefit
eob-item- A set of codes which 1..1 Coding http://ns.electronichealth.net.au/f
service specifies the benefit hir/v2.0.0/StructureDefinition/eob
item accessed by the -item-service
patient.

Resource ExplanationOfBenefit
patient- A set of codes which 1..1 code http://ns.electronichealth.net.au/f
access- specifies the Patient hir/v2.0.0/StructureDefinition/pati
criteria Access Criteria. ent-access-criteria

90 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Appendix F Terminologies
This table contains a list of all the value sets and code systems defined as part of
the My Health Record System FHIR specification.

Table 61 - Terminologies

ID Description Type Defining URL

eob-item- CodeSystem for CodeSystem http://ns.electronichealth.net.au/fhir/v2.0.0/Code
service Explanation Of System/eob-item-service
Benefit Item Service

eob-item- This is a value set ValueSet http://ns.electronichealth.net.au/fhir/v2.0.0/Value

service that includes set of Set/eob-item-service
codes which
specifies the benefit
item accessed by
the patient.
relationship- CodeSystem for CodeSystem http://ns.electronichealth.net.au/fhir/v2.0.0/Code
type Relationship Type System/relationship-type

relationship- This is a value set ValueSet http://ns.electronichealth.net.au/fhir/v2.0.0/Value

type that includes all the Set/relationship-type
codes for
relationship type.

patient- This code system CodeSystem http://ns.electronichealth.net.au/fhir/v2.0.0/Code

access- includes all the System/patient-access-criteria
criteria codes for Patient
Access Criteria as
per My Health
Record System"

patient- This is a value set ValueSet http://ns.electronichealth.net.au/fhir/v2.0.0/Value

access- that includes all the Set/patient-access-criteria
criteria codes for Patient
Access Criteria.

17 June 2019 Approved for external use 91 of 94

DH-2751:2018
Australian Digital Health Agency

Appendix G Operations
The table below describes the custom FHIR operation defined by My Health Record System

Table 62 - Operations

ID Description Applicable Interaction Defining URL

Resource Type
patient- The 'access' Patient POST http://ns.electronichealth.net.au/f
access operation allows the hir/v2.0.0/OperationDefinition/pati
Provider to gain ent-access
access to the Patient
record so that they
can view the details
associated with the
Patient

92 of 94 Approved for external use 17 June 2019

DH-2751:2018
My Health Record FHIR® Gateway
API Specification v2.0.0

Acronyms
Acronym /Term Meaning

API Application Programming Interface

FHIR® Fast Healthcare Interoperability Resources

[base] The Service Root URL. The Service Root URL is the address where all of the
resources defined by this interface are found. The Service Root URL takes the
form of “http(s)://server{/path}”

IHI Individual Healthcare Identifier

JSON JavaScript Object Notation

MBS Medicare Benefits Schedule

NIO National Infrastructure Operator

NOC Notice of Connection

OAuth Open Authorisation

PBS Pharmaceutical Benefits Schedule

Patient Individual having a My Health Record

REST Representational State Transfer

SVT Software Vendor Testing

XML Extensible Mark-up Language

[fqdn] The Gateway’s fully qualified domain name

17 June 2019 Approved for external use 93 of 94

DH-2751:2018
Australian Digital Health Agency

References
FHIR® Documentation: http://hl7.org/fhir/2016May/index.html

94 of 94 Approved for external use 17 June 2019

DH-2751:2018

Health Cloud Dev Guide
No ratings yet
Health Cloud Dev Guide
2,114 pages
Health Cloud Dev Guide
No ratings yet
Health Cloud Dev Guide
1,936 pages
(Ebook PDF) Documentation For Health Records 2nd Edition PDF Download
100% (1)
(Ebook PDF) Documentation For Health Records 2nd Edition PDF Download
52 pages
Documentation For Health Records, 2nd Edition Full-Resolution Download
100% (15)
Documentation For Health Records, 2nd Edition Full-Resolution Download
15 pages
MCQ On Animal Husbandry
100% (7)
MCQ On Animal Husbandry
4 pages
Clinical User Guide 2015 Merged
No ratings yet
Clinical User Guide 2015 Merged
274 pages
EHR Standards 2016 MoHFW
No ratings yet
EHR Standards 2016 MoHFW
48 pages
Wikipedia Handbook of Biomedical Informatics
100% (1)
Wikipedia Handbook of Biomedical Informatics
709 pages
Nrces Ehr Stand India
No ratings yet
Nrces Ehr Stand India
56 pages
Che 1211 Module 2
100% (1)
Che 1211 Module 2
41 pages
CIP, SIP, Prefilled Syringe
No ratings yet
CIP, SIP, Prefilled Syringe
78 pages
DOC20220330133829ROSIA TD2 Challenge Brief
No ratings yet
DOC20220330133829ROSIA TD2 Challenge Brief
99 pages
Applicability Statement For Secure Health Transport: Version 1.1, 10 July 2012
No ratings yet
Applicability Statement For Secure Health Transport: Version 1.1, 10 July 2012
20 pages
FHIR For Developers
100% (3)
FHIR For Developers
159 pages
Unofficial Developer S Guide To FHIR On Mirth Connect PDF
No ratings yet
Unofficial Developer S Guide To FHIR On Mirth Connect PDF
21 pages
MyChart Features List
No ratings yet
MyChart Features List
9 pages
EEHRxF Community of Excellence 04072025
No ratings yet
EEHRxF Community of Excellence 04072025
46 pages
HHS Interim Final 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria For Electronic Health Record Technology
No ratings yet
HHS Interim Final 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria For Electronic Health Record Technology
136 pages
MicroProfile Health Checks
No ratings yet
MicroProfile Health Checks
37 pages
EMR Guidelines - MOHFW
100% (1)
EMR Guidelines - MOHFW
48 pages
Standards For National Health Claim Exchange (NHCX)
No ratings yet
Standards For National Health Claim Exchange (NHCX)
41 pages
TAP 21 Addiction Counseling Competencies
100% (8)
TAP 21 Addiction Counseling Competencies
223 pages
Uw Fhir Workshop-Intro To Fhir
No ratings yet
Uw Fhir Workshop-Intro To Fhir
56 pages
Comptia HIT
No ratings yet
Comptia HIT
280 pages
Final Rule MU Standards Quick List With CFR Citation Cross Walked To The Standard
No ratings yet
Final Rule MU Standards Quick List With CFR Citation Cross Walked To The Standard
17 pages
Simone Heckmann FHIR Proficiency Prep Course DevDays 2019 Redmond
No ratings yet
Simone Heckmann FHIR Proficiency Prep Course DevDays 2019 Redmond
35 pages
Security Logging and Monitoring Policy EN
No ratings yet
Security Logging and Monitoring Policy EN
17 pages
FHIR ImplementationGuide 28july
No ratings yet
FHIR ImplementationGuide 28july
62 pages
Electronic Health Record
100% (2)
Electronic Health Record
29 pages
Lijimol C February Assignment
No ratings yet
Lijimol C February Assignment
6 pages
Electronic Health Records
No ratings yet
Electronic Health Records
9 pages
Hhs Transcript Module
No ratings yet
Hhs Transcript Module
5 pages
Electronic Health Record Finalll
No ratings yet
Electronic Health Record Finalll
31 pages
Digital Communications and Networks: Yaira K. Rivera S Anchez, Steven A. Demurjian, Mohammed S. Baihan
No ratings yet
Digital Communications and Networks: Yaira K. Rivera S Anchez, Steven A. Demurjian, Mohammed S. Baihan
12 pages
Final Final HIS Word
No ratings yet
Final Final HIS Word
68 pages
Security and Privacy of Electronic Health Records: Concerns and Challenges
No ratings yet
Security and Privacy of Electronic Health Records: Concerns and Challenges
7 pages
Personal Health Records
No ratings yet
Personal Health Records
15 pages
Standards List
No ratings yet
Standards List
36 pages
Getting Started Guide
No ratings yet
Getting Started Guide
5 pages
Interoperability Workshop S4 Russell Leftwich
No ratings yet
Interoperability Workshop S4 Russell Leftwich
41 pages
Electronic Health Records - Australian Government Department of Health and Aged Care
No ratings yet
Electronic Health Records - Australian Government Department of Health and Aged Care
2 pages
FBS Module 5
100% (1)
FBS Module 5
3 pages
Emr Specification V4.1a - Appendix F - Mar082013 v1
No ratings yet
Emr Specification V4.1a - Appendix F - Mar082013 v1
33 pages
Real World Testing-Results Report AaNeel 2023
No ratings yet
Real World Testing-Results Report AaNeel 2023
7 pages
Medical App Draft
No ratings yet
Medical App Draft
2 pages
1.3requirements Analysis
No ratings yet
1.3requirements Analysis
11 pages
Bok1 015872
No ratings yet
Bok1 015872
34 pages
PD233 Lecture16
No ratings yet
PD233 Lecture16
17 pages
13 ElectronicHealthRecord
100% (1)
13 ElectronicHealthRecord
48 pages
John's Case Study
No ratings yet
John's Case Study
8 pages
UHI Apps and LLM
No ratings yet
UHI Apps and LLM
8 pages
Documentation For Health Records - 2nd Edition All Chapter
No ratings yet
Documentation For Health Records - 2nd Edition All Chapter
15 pages
NURS FPX 6412 Assessment 3 Manuscript For Publication
No ratings yet
NURS FPX 6412 Assessment 3 Manuscript For Publication
4 pages
Learning HL7 FHIR Using The HAPI FHIR Server and I
No ratings yet
Learning HL7 FHIR Using The HAPI FHIR Server and I
7 pages
Intro To FHIR Resources Fact Sheet
No ratings yet
Intro To FHIR Resources Fact Sheet
2 pages
Electronic Health Record
No ratings yet
Electronic Health Record
11 pages
His Finals - Lab 1
No ratings yet
His Finals - Lab 1
3 pages
DEVPSYCH - Chapter 1 PDF
No ratings yet
DEVPSYCH - Chapter 1 PDF
8 pages
52 10 00 MP PDF
100% (1)
52 10 00 MP PDF
70 pages
Science Olympiad Disease Detective Cheat Sheet
No ratings yet
Science Olympiad Disease Detective Cheat Sheet
3 pages
Module 4. Practice Set 6 Answers
0% (1)
Module 4. Practice Set 6 Answers
2 pages
FCC Catalyst Coolers Open Window To Increased Propylene
No ratings yet
FCC Catalyst Coolers Open Window To Increased Propylene
11 pages
HP3325A Synthesizer-Function Generator Op-Service Manual 03325-90002 PDF
No ratings yet
HP3325A Synthesizer-Function Generator Op-Service Manual 03325-90002 PDF
397 pages
Consumable Las
No ratings yet
Consumable Las
35 pages
UNIT I Health Psycholohy
No ratings yet
UNIT I Health Psycholohy
21 pages
Tutorial 10 (Exercise)
No ratings yet
Tutorial 10 (Exercise)
1 page
Dynamo Dynamics
No ratings yet
Dynamo Dynamics
11 pages
Green Printing: Inevitability For Printing Industry Sustainability
No ratings yet
Green Printing: Inevitability For Printing Industry Sustainability
4 pages
Resume Emily Pomykala
No ratings yet
Resume Emily Pomykala
2 pages
PEX - Installation Simulator
No ratings yet
PEX - Installation Simulator
17 pages
Treating Ed - Ethics
50% (2)
Treating Ed - Ethics
6 pages
Digital Citizenship PDF
No ratings yet
Digital Citizenship PDF
2 pages
Oiv Ma As323 01b
No ratings yet
Oiv Ma As323 01b
4 pages
Dharma Rath Ne 2020
No ratings yet
Dharma Rath Ne 2020
6 pages
AdyaRitu Kala Ritusuddhi Samskarah - Wikipedia
No ratings yet
AdyaRitu Kala Ritusuddhi Samskarah - Wikipedia
8 pages
Specification: KADPOL 980 / 941 / 940
No ratings yet
Specification: KADPOL 980 / 941 / 940
1 page
Practice Question Set 3 Elective - 19 - 07 - 24 - 240810 - 100717
No ratings yet
Practice Question Set 3 Elective - 19 - 07 - 24 - 240810 - 100717
7 pages
Crop Yield Prediction and Efficient Use of Fertilizers
No ratings yet
Crop Yield Prediction and Efficient Use of Fertilizers
3 pages
Exploring The Unexpected Link Between Per Capita Margarine Consumption and Divorce Rates in Maine
No ratings yet
Exploring The Unexpected Link Between Per Capita Margarine Consumption and Divorce Rates in Maine
1 page
6.8. Corporate Code of Conduct
No ratings yet
6.8. Corporate Code of Conduct
3 pages
18-0002PCC Data Pump ASH 40 Peristaltica
No ratings yet
18-0002PCC Data Pump ASH 40 Peristaltica
2 pages
Bechayda, Act. 1
No ratings yet
Bechayda, Act. 1
1 page

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.