This Developer Guide provides guidance for developers on how to test their NASH SHA-2 software enhancements and submit evidence of their product’s readiness to the Agency for assessment.
This Developer Guide is for the use of developers whose products connect to the Healthcare Identifiers (HI) Service, My Health Record, Electronic Prescribing and Secure Messaging with a National Authentication Service for Health (NASH) PKI Certificate.
This process defines the steps for prescribing and/or dispensing Clinical Information System (CIS) software developers that connect to an open Prescription Delivery Service (PDS) to declare software conformance with the Agency’s Electronic Prescribing technical framework.
Reading & Development: 2 hours. In this guide, we will cover; How to implement CIS to NPP into your software, Solution overview and Conformance Test Requirements
Reading 15 minutes, Registration 30 minutes. Learning objectives: In this guide, you'll learn, Introduction to CIS to NPP service, CIS to NPP Limitations, Register for CIS-to-NPP implementation, Testing, Vendor conformance process and Go Live requirements
My Health Record is a secure online summary of an individual’s health information and is available to all Australians. Healthcare providers authorised by their healthcare organisation can access My Health Record to view and add patient health information.
To better meet the expectations and requirements of developers, the Agency now provides sample code libraries directly from GitHub and NuGet.
The My Health Record Integration Toolkit contains sample code for B2B connectivity to the My Health Record system.
The HI Integration Toolkit is a collection of sample code available in both .NET and Java. This toolkit is available for download via this website, GitHub and NuGet. If you are following the HI Service Developer Guides, you will download the .NET NuGet package in Guide 1.
The My Health Record integration toolkit contains libraries for business-to-business (B2B) connectivity to the My Health Record system. The toolkit provides sample code for all operations, schemas used and sample SOAP request and response messages.
The eHealth integration toolkits are a collection of integration tools and sample code resources available in both .NET and Java. The sample code and integration tools are used within the eHealth Reference Platform, forming part of the code library for tools and simulators.
This Developer Guide provides guidance for developers on how to test their NASH SHA-2 software enhancements and submit evidence of their product’s readiness to the Agency for assessment.
This Developer Guide is for the use of developers whose products connect to the Healthcare Identifiers (HI) Service, My Health Record, Electronic Prescribing and Secure Messaging with a National Authentication Service for Health (NASH) PKI Certificate.
This process defines the steps for prescribing and/or dispensing Clinical Information System (CIS) software developers that connect to an open Prescription Delivery Service (PDS) to declare software conformance with the Agency’s Electronic Prescribing technical framework.
Reading & Development: 2 hours. In this guide, we will cover; How to implement CIS to NPP into your software, Solution overview and Conformance Test Requirements
Reading 15 minutes, Registration 30 minutes. Learning objectives: In this guide, you'll learn, Introduction to CIS to NPP service, CIS to NPP Limitations, Register for CIS-to-NPP implementation, Testing, Vendor conformance process and Go Live requirements
In this guide, you will; Understand high level concepts regarding the HI Service, Register as a developer for the HI Service, Request Test Certificates and Test Environment Data, Install the Test Certificates locally and Import Certificates in CIS Software
My Health Record is a secure online summary of an individual’s health information and is available to all Australians. Healthcare providers authorised by their healthcare organisation can access My Health Record to view and add patient health information.
The following steps will assist software developers who provide open Prescription Delivery Service (PDS) and/or Active Script List Registry capabilities to declare software conformance with the Agency’s Electronic Prescribing technical framework.
The following steps will assist Clinical Information System (CIS) software developers with a direct Prescription Delivery Service (PDS), declare software conformance with the Agency’s Electronic Prescribing technical framework. A direct PDS generally provides the capability to prescribe and dispense, without the requirement to dispense from a community pharmacy. Often this model is used within a hospital environment where the hospital pharmacy will dispense the medication.
In this guide, we will be accessing these 2 document types via the following 2 APIs, PBS Items (GET) and MBS Items (GET)
This guide will look at retrieving all clinical document data (including these 2, but excluding MBS documents).
In this guide, we will be accessing Prescription and Dispense List and Allergies List contained in a patient’s clinical document service.
In this guide, we will be accessing a patient’s medications and allergies contained in a Personal Health Summary. A Personal Health Summary is a specific type of clinical document which has been completed by the consumer, most often without the assistance of a healthcare professional.
To begin this guide you should have completed the previous 2 guides, have registered as a developer, and successfully developed MyGov authentication functionality. We will use the token received from MyGov to access the patient’s My Health Record.
Within these guides we will demonstrate the functionality of the FHIR Gateway using Xamarin.Forms in Visual Studio and the Android Emulator.
This guide is focused on the FHIR Gateway (also previously known as the Mobile Gateway).
If you are connecting to the HI Service for the purpose of implementing Electronic Prescriptions, some of the existing HI Service test cases will now be mandatory instead of recommended.
This guide walks through the steps to access a patient’s My Health Record using the GainPCEHRAccess web service. When gaining access to a patient’s My Health Record, it is important to understand Access Codes and Emergency Access.
This developer guide helps you to verify whether a My Health Record exists for a patient using their Individual Healthcare Identifier (IHI). If you have not already done so, you should follow our HI Service Developer Guides.
This guide will describe the steps to remove a Clinical Document. If your software product uploads Clinical Documents then you must have the option for your users to remove Clinical Documents that they have uploaded.
This guide describes the steps to supersede a Clinical Document in the My Health Record system. The ability to supersede a document is a requirement of uploading (unless your software only uploads Shared Health Summaries).
This guide will walk through the steps to create and upload clinical documents. The following steps are involved in this process.
This guide will use the My Health Record getView web service to download collated information from a My Health Record in a ‘View’. A view is simply a representation of data from a My Health Record which has been collated from multiple clinical documents.
This guide will walk through the process to get patient clinical documents from the My Health Record system and display them to your users using a generic style sheet. To retrieve documents you must already have conducted a GainPCEHRAccess call as conducted in the previous guide.
After successfully executing the IHI Lookup, it is important to modify your implementation to meet the Test Cases for the Use Cases we have built to. Continued from: IHI Lookup - HI Service Developer Guide 1
It is highly recommended that your software conduct HPI-I searches for users of your system. The primary reason for this is that most healthcare provider individuals do not know their HPI-I number however their AHPRA number is often known.
Your software will need to conduct lookups for Individual Healthcare Identifiers (IHIs) for patients. This is conducted when registering a new patient, updating a patient in your local system, and in some other specific circumstances. This can be done in batch, or individually. Our example will focus on looking up a patient IHI individually.
The Business-to-Business (B2B) Gateway services allow a range of systems to access the My Health Record system, such as clinical systems, systems integrated via a gateway, and contracted service providers acting on behalf of healthcare organisations.
Audience
The HI Integration Toolkit is a collection of sample code available in both .NET and Java. This toolkit is available for download via this website, GitHub and NuGet. If you are following the HI Service Developer Guides, you will download the .NET NuGet package in Guide 1.
The My Health Record integration toolkit contains libraries for business-to-business (B2B) connectivity to the My Health Record system. The toolkit provides sample code for all operations, schemas used and sample SOAP request and response messages.
The eHealth integration toolkits are a collection of integration tools and sample code resources available in both .NET and Java. The sample code and integration tools are used within the eHealth reference platform, forming part of the code library for tools and simulators.
The eHealth integration toolkits are a collection of integration tools and sample code resources available in both .NET and Java. The sample code and integration tools are used within the eHealth Reference Platform, forming part of the code library for tools and simulators.
The Clinical Package Validator is a tool to automate some of the tests needed to assess conformance of clinical documents and clinical packages with the eHealth Specifications.
The Information Quality Rules (IQ Rules) is a tool that helps developers, testers and analysts determine the quality of clinical documents including the conformance of clinical documents to the My Health Record system conformance requirements.
The My Health Record Integration Toolkit contains sample code for B2B connectivity to the My Health Record system.
The Clinical Package Validator (Validator) provides software developers with enhanced capabilities to achieve a greater degree of automation and depth of their conformance tests of clinical documents.
To better meet the expectations and requirements of developers, the Agency now provides sample code libraries directly from GitHub and NuGet.
The Agency has released updates for the following products Clinical Documents Integration Toolkit v1.8 and Health Record Overview v1.2
By operation of the Public Governance, Performance and Accountability (Establishing the Australian Digital Health Agency) Rule 2016, on 1 July 2016, all the assets and liabilities of NEHTA will vest in the Australian Digital Health Agency. In this website, on and from 1 July 2016, all references to "National E-Health Transition Authority" or "NEHTA" will be deemed to be references to the Australian Digital Health Agency. PCEHR means the My Health Record, formerly the "Personally Controlled Electronic Health Record", within the meaning of the My Health Records Act 2012 (Cth), formerly called the Personally Controlled Electronic Health Records Act 2012 (Cth).
