ADHA & MSIA Joint Information Sharing and Q&A - 29 November 2022
Events
A joint Q&A session where MSIA members will receive agency updates, and have the chance to ask general questions about any projects or programs of work.
A joint Q&A session where MSIA members will receive agency updates, and have the chance to ask general questions about any projects or programs of work.
The final steps to move from the current Oracle API Gateway to the new Health API Gateway, which facilitates connections to My Health Record, will go into production as a staged process nationwide, beginning 17 November. We anticipate the full rollout will take 2-3 weeks.
The Agency led the development of the Interoperability Plan in partnership with Commonwealth, state and territory government health departments, peak bodies, clinicians, consumers and software developers.
Monthly opportunity to meet with and pick the brains of the CEO and available Board members.
From 25 May 2022, software systems and any application using interaction model 4 and provider apps to connect to the My Health Record Software Vendor Test (SVT) environment must trust the new My Health Record public SSL certificates.
Request For Information - Log4j and Spring Framework vulnerabilities - Please do this by completing the short questionnaire by 14 June 2022
The Department of Health's Digital Transformation agenda is working to create a better-connected aged care network, that is consolidated, sustainable, automated, and modern.
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
To better meet the expectations and requirements of developers, the Agency now provides sample code libraries directly from GitHub and NuGet.
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 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 walk through the steps to create and upload clinical documents. The following steps are involved in this process.
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.
From 25 May 2022, software systems and any application using interaction model 4 and provider apps to connect to the My Health Record Software Vendor Test (SVT) environment must trust the new My Health Record public SSL certificates.
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.
The final steps to move from the current Oracle API Gateway to the new Health API Gateway, which facilitates connections to My Health Record, will go into production as a staged process nationwide, beginning 17 November. We anticipate the full rollout will take 2-3 weeks.
Request For Information - Log4j and Spring Framework vulnerabilities - Please do this by completing the short questionnaire by 14 June 2022
To better meet the expectations and requirements of developers, the Agency now provides sample code libraries directly from GitHub and NuGet.
The Agency is very keen to understand and get feedback from the medical software industry on some key topics within the Guidelines.
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).