This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on http://medinform.jmir.org/, as well as this copyright and license information must be included.
My Health Record (MyHR) is Australia’s national electronic health record (EHR) system. Poor usability and functionality have resulted in low utility, affecting enrollment and participation rates by both patients and clinicians alike. Similar to apps on mobile phone app stores, innovative third-party applications of MyHR platform data can enhance the usefulness of the platform, but there is a paucity of research into the processes involved in developing third-party applications that integrate and use data from EHR systems.
The research describes the challenges involved in pioneering the development of a patient and clinician Web-based software application for MyHR and insights resulting from this experience.
This research uses a case study approach, investigating the development and implementation of
The study presents a nuanced understanding of different data types and quality of data in MyHR and the complexities associated with developing secondary-use applications. Regulatory requirements associated with utilization of MyHR data, restrictions on visualizations of data, and processes of testing third-party applications were encountered during the development of the application.
This study identified several processes, technical and regulatory barriers which, if addressed, can make MyHR a thriving ecosystem of health applications. It clearly identifies opportunities and considerations for the Australian Digital Health Agency and other national bodies wishing to encourage the development of new and innovative use cases for national EHRs.
Across the member countries of the Organisation for Economic Co-operation and Development, national electronic health records (EHRs) are at varying stages of implementation [
As in the United Kingdom, Australia’s MyHR is suffering from lack of buy-in from patients. Since its launch in 2012, uptake of MyHR has been insufficient to achieve the critical mass of patient participation necessary to galvanize health care provider engagement [
Unlike the United Kingdom and Australia, the United States adopted a bottom-up approach to the development of a national EHR system. The strategy in the United States was a staged approach focusing on “meaningful use” [
In Australia, the initial focus of third-party software development for MyHR was on software integrating MyHR into existing clinical information systems. By clinical information systems, we mean computer-based systems for managing and storing in-patient or practice-based medical records and test results for the delivery of patient care in local settings such as a general practice (GP) or a hospital [
In Australia, there are 2 factors that influence the usefulness of MyHR—the type of data sources available and the functionality of the system. First, MyHR is currently missing a coherent approach to automatically source data from health care providers and other repositories of health data, resulting in incomplete data. The most complete and up-to-date data currently available on MyHR are Medicare data. Medicare is Australia’s universal care provider. The Medicare claims database records medical intervention claims reimbursed through the Medical Benefits Scheme (MBS) and pharmaceutical prescriptions and dispensing claims reimbursed through the Prescription Benefit Scheme (PBS). Second, although access to fragmented medical history in a single place is one of the main perceived benefits and utility of EHRs [
In this research, we review the development of a third-party application called
EHRs involve the exchange of information with other health care systems and repositories of health care data [
Health data stored in MyHR are programmatically accessible in a format known as views. There are 11 different views for different types of data as shown in
A notable exception to the above is data stored under the Medicare view, which contains details directly populated from the Medicare claims database. It consists of a list of reimbursed MBS and PBS interventions. The Medicare records are complete and, on creation of a MyHR, the system automatically uploads retrospective data for 2 years from the date of activation of a MyHR account and then subsequently automatically updates records after each and every intervention.
Medicare data record reimbursement claims for dispensed prescriptions and administered interventions such as diagnostic and therapeutic procedures, oral and maxillofacial, diagnostic imaging, and pathology services, as well as data from allied health and optometry services.
Overview of data input into My Health Record (myHR).
Data fields for Medicare data.
Medical Benefits Scheme data | Prescription Benefit Scheme data |
Date of service | Generic name |
Item numbera | Brand |
Item descriptionb | Date prescribed |
Name of practitioner | Date supplied |
In hospital (yes/no) | Form and strength |
Quantity | |
Number of repeatsc | |
Code |
aMedicare Benefits Schedule outlining item numbers [
bFor example, “consultation and consulting rooms, Level B” or “Initial Specialist Attendance, MRI scan for derangement of shoulder or its supporting structures.”
cNumber of repeat prescriptions left.
AI Squared Medical Benefits Scheme (MBS) and Prescription Benefit Scheme (PBS) data timeline visualization. GP: general practice.
The data detail the date of visit to a supplier of Medicare-funded services and the specific services or tests performed as described in the medical benefits schedule [
AI2 is designed as a responsive Web application that visualizes MyHR Medicare view data in the form of a timeline view. It has patient and clinician interfaces but is designed to be a standalone application accessible by registered patients even when there is no interaction with health professionals involved. Thus, it is the first patient analytics-oriented third-party application interfacing with MyHR.
Medicare view data are a by-product of administrative claims processing. So, to provide an initial level of useful analytics, AI2 uses a simple taxonomy to map administratively used item types and prescription codes into clinically relevant categories. The clinical categories are based on the intervention provider type or medication names for each disorder. The mapping involved creating a parser that groups item numbers associated with similar service providers (eg, GPs, psychiatrists) and grouping of prescriptions associated with same disorders such as antidepressants. The result of grouping data and using the timeline format is that it is easier to quickly visualize a patients’ trajectory and gaps over time; see
The benefit for patients is that AI2 provides an intuitive timeline interface that can facilitate the management of their health, by collating pharmaceutical and health provider encounters. AI2 is most likely to benefit patients with severe mental illnesses or chronic disease, with ongoing medications and treatment through multiple care providers, by easing the burden of managing or recalling extensive history of polypharmacy and medical information across multiple health care providers [
For clinicians, understanding the patient history is an essential part of the patient interview [
This research is a case study of a pioneering development of a third-party application for MyHR. Although the AI2 application has not been officially released as it is currently undergoing trials, it was nonetheless the first third-party application developed for MyHR. As such, it was a test case for the Australian Digital Health Agency and other developers of MyHR. This case study identifies the challenges encountered by the Personal Health Informatics team from Flinders University, in the development of a third-party application for MyHR. The research identifies opportunities and considerations for the Australian Digital Health Agency and other national bodies wishing to encourage the development of new use cases for national EHRs. Having a functional and efficient third-party application development environment is important because application can “stimulate open innovation and competition for products that deliver on consumer and health care provider expectations in the digital health space, and ultimately contribute to improved health care outcomes for people” [
The development of the AI2 application involved implementing interface programs to access Medicare data, applying timeline visualizations on obtained Medicare data, and testing conformance requirements. The application was developed using open-source development and hosting tools. It is developed in Java Enterprise Edition using JBoss Seam and Hibernate frameworks. The database is created in PostgreSQL. JBoss Application servers and APACHE Web servers are required to run the compiled application. Implementation of a third-party application that interfaces with MyHR involved integration with 2 Web services known as Health care Identifiers verification (HI) Service, maintained by Medicare Australia, and MyHR Service from the Australian Digital Health Agency. HL7 SOAP protocol is used for integration with HI and MyHR Web services. The resulting application is developed to be registered as a stand-alone “health service” that can be accessed directly by the patients with or without a treating clinician and satisfy the requirements of 2012 Australian MyHR legislation. The source code of the application is available for the development of future patient-oriented applications and the corresponding author can be contacted to request access.
AI2 was designed with 2 types of users in mind: patients and clinicians. The application can be used independently either by patients, for self-monitoring, or by clinicians for checking on care plans or compliance or as a tool for both patient and clinician to verify patient history and discuss events, care plans, or treatments. Either the patient or the clinician can create an AI2 record.
Using test data, we created a patient record on MyHR. Creating a patient record on AI2 involves setting up a username, which is a mobile phone number and password as well as providing details required for the purposes of verifying Individual Health Identifier (IHI) with the HI service. To do this, patients can either provide their 16-digit IHI number, or alternatively provide other details (first name, last name, date of birth, gender, and Medicare number). The application sends this information to HI service for verification, and on receiving a valid user confirmation, a user record is created in the AI2 database.
The registration page for clinicians is similar, as it also involves entering a mobile number and password similar to the patient users. The registration page also has the capacity to collect the 16-digit Healthcare Provider Identifier (HPI-I), another unique identifier used by MyHR for verifying health professionals. All clinicians automatically have a Healthcare Provider Number, which is their Australian Health Practitioner Regulation Agency ID number with the addition of “800361” digits before [
The process for fetching data from MyHR within AI2 involves, first, verifying that the individual has an activated MyHR, and on successful confirmation, gaining access to MyHR database. After receiving successful confirmation, the application then fetches health data using “Getview” APIs. The application is programmed to extract the latest records from MyHR whenever a patient profile is opened by either a patient or a clinician. Patients can also view a list of AI2-registered clinicians and can control which of these clinicians has access to their data using a connect or disconnect button.
Registered clinicians have to be connected to a patient user before they can view the patient’s record. The application can be configured to allow clinicians either to be automatically connected to all or selectively connected to registered patient users. If a clinician is not designated to have automatic connection with all individuals, they can search for patients by name, date of birth, gender, and Medicare number to find matching patients and connect, as is current practice in hospitals.
The AI2 application applies a visually rich interactive timeline visualization on Medicare view data, implemented using vis.js and timeline.js, 2 open-source, browser-based visualization libraries. The timeline visualization displays each MBS and PBS claim stored in Medicare view as an event against a timescale on horizontal axis (see
MyHR consists of a centralized infrastructure to verify, obtain, and transfer health information of individuals from repositories holding health and clinical documents. It is designed to interact with several distributed repositories, some of which are established and managed centrally by the Australian Digital Health Agency, and others are maintained by registered external organizations, including Medicare. The central infrastructure is designed to query and identify the repositories that contain information about an individual patient using their unique identifier, known as Individual Healthcare Identifier (IHI) and to collate available data on request from the repositories.
Timeline visualization of Medical Benefits Scheme (MBS) data over a number of years. PBS: Prescription Benefit Scheme.
Links between systems in the third-party application development environment. Continuous lines represent automatic push of information or data. Dashed lines represent push data on request of information or data. GP: general practice; MyHR: My Health Record.
Developing and administering the AI2 application involves hosting the infrastructure on a server and meeting eligibility criteria to be a host organization by the Australian Digital Health Agency. The host organization, in this case, Flinders University, must adopt a MyHR use policy, register to be a MyHR “participating organization,” and apply to obtain a Health Provider Identifier. The purpose of MyHR’s use policy was to ensure that organizations are accessing data through conformant software for providing health care only.
To develop a MyHR application for patients and or clinicians, the first step was to register as an application developer with Medicare and the Australian Digital Health Agency , after which access is granted to a development environment and a test kit containing sample data for testing and descriptions of supported integration use cases.
The Personal Health Informatics team from Flinders University was registered as a software developer with Medicare Australia and the Australian Digital Health Agency to gain access to developer and testing environments. At the time of the development of AI2, access was restricted to applications developed for the purposes of providing “health service” as defined in the Privacy Act 1988 (Cwlth) as follows:
(a) an activity performed in relation to an individual that is intended or claimed (expressly or otherwise) by the individual or the person performing it:
(i) to assess, record, maintain or improve the individual’s health; or
(ii) to diagnose the individual’s illness or disability; or
(iii) to treat the individual’s illness or disability or suspected illness or disability; or
(b) the dispensing on prescription of a drug or medicinal preparation by a pharmacist.
The interpretation of this act presupposes the involvement of a clinician. There were no special provisions for the development of patient portals, which therefore were also required to meet the definition of providing a “health service.” Thus, a case was argued with the Department of Health that the analysis provided by the AI2 met the criteria of providing a “health service” by providing patients with health data insights. Flinders University was given as a unique 16-digit identifier as a “health services provider” under the auspices of Healthcare Identifiers Act 2010 (Cwlth) (21).
Software integration with Healthcare Identifiers verification service (HI) and My Health Record (MyHR) service. AI2: AI Squared; B2B API: Business 2 Business application programming interfaces.
As would be expected on a national EHR, there are strict technical and intended use requirements. AI2 and other third-party software that integrates with MyHR had to meet conformance requirements of both the HI service and the My Health Record to demonstrate that the application could first exchange information with the HI service, and second, pass conformance tests to ensure the information exchange was consistent with approved use cases and rendering guidelines for displaying information from MyHR. Each test, 4 tests in all, took between 3 and 6 months.
The testing process involved first creating test cases, and subsequently, remotely assessing these test cases using the sample data provided in the test kit. Sample datasets in the test kit were mainly aimed at testing the authentication and data access process and not utilization needs. They neither contained longitudinal records nor did they have a sufficient number of test cases required for refining the visualization categories. Thus, it was necessary for us to use data sourced from a different study to develop the timeline analytics [
The first test, with the HI Service, the Notice of Connection (NOC) test, involved taking a screenshot and log file based on test cases, which were then approved by testers at the Department of Health.
After completing the NOC test, the second test, the HI conformance test, was conducted by IV&V Australia, an accredited tester at a cost of Aus $10,000. On passing the HI service conformance tests, the Department of Health issued an approval letter with details to gain access to the production HI Service.
The third test, the MyHR NOC test, was carried out by Ventura Inc. at no cost. Testing involved verifying that appropriate warnings and alerts were displayed in the application for incorrect individual details included in sample data. A tester from Accenture PLC remotely monitored the application, while the developer tested different patient and clinician scenarios, also at no cost. The fourth and final test, the MyHR conformance test of rendering guidelines, was done via a self-assessment form.
Displaying timeline visualizations of Medicare data obtained from MyHR required overcoming several standards-related challenges. To meet the software conformance standards, health data had to be displayed in a predefined format and style guidelines set by the Australian Digital Health Agency [
On completion of all 4 conformance tests, the Department of Health issued a letter of approval, granting access to the MyHR production server through the AI2 application.
To use the AI2 application, an organization must register with the Australian Digital Health Agency and obtain an HPI-O number, which is a unique 16-digit organization number verifiable by the HI service as well as a National Authentication Service for Health Public Key Infrastructure Certificate, a digital certificate for activating the conformant software AI2 application. Both these details need to be keyed into AI2 before the platform can make connections with live MyHR. Both clinicians and patients have to read and consent to the terms of use for the AI2 service and the privacy policy of the AI2 application, which were developed in consultation with the Flinders University legal team. The privacy policy contains information on user obligations and outlines how information sourced from MyHR are used and managed. After this process, the South Australian Health and Medical Research Institute is registered as the “participating organization,” and an instance of the AI2 application for supporting psychiatric patients is hosted on Nectar, a cloud server infrastructure available for Australian university researchers under the AI2 website [
Developing a third-party patient application for EHRs has been previously attempted and deemed difficult [
First, at the time of the development of AI2, the focus of development of third-party applications was predominantly on development of clinical health information systems. A major challenge in the development of AI2 was to understand how a patient-centered third-party application might meet these requirements.
All third-party conformant software has to interface with MyHR via the provider portal. To do so, at the time, providers had to be recognized as a “health service provider,” defined by the MyHR legislation [
Circumventing the definition of “health service provider” has 2 possible interpretations, one is to consider the application itself as a “health service provider”, and the other is to consider the organizations creating and hosting standalone patient-oriented applications of MyHR as “health service” providers. Either way, defining the software or the software development companies as “health service” may raise issue of regulation.
Treating the software itself as a “health service provider” feeds into the growing debate on the need for standards and regulation-related health service provision for standalone applications of personal health interventions [
Treating software development companies as health service providers may result in more opportunities for creating new applications using MyHR data; however, health services providers, in particular, professional health services providers, are strictly regulated [
Another challenge raised by framing MyHR third-party software development as “health service” provision is a restriction on use and, in particular, restrictions on use for research and analysis which do not meet the criteria of the My Health Record 2012 (Cwlth) legislation. Paradoxically, the restriction on use only applies to retrieving data from MyHR. Once the information is lawfully obtained from MyHR, local terms of use and privacy policy within the application can be applied for subsequent utilization of downloaded data to support new use cases such as in the case of AI2, future plans for providing treatment decision support, data linkage endeavors, or recruitment for clinical trials [
The quality of and completeness of records/data available via MyHR varies substantially and is a major limitation for the development of new use cases with MyHR. The completeness and therefore the value of information under each of the views depends on, for some records such as GP-shared summaries, whether the patient permission to upload has been granted, whether the service provider has the technology to upload to MyHR, and whether the data upload happens automatically. Currently, only Medicare data are complete and up-to-date and, therefore, potentially useful for innovative analytics and clinical trial use cases.
Developing and using MyHR data for analytics applications for MyHR also presents 2 data processing challenges. The first relates to standards and interoperability. The data held by MyHR from the clinical repositories are analogous to shared file repositories, such as Dropbox. With the exception of Medicare data, data in MyHR from sources such as hospital and GPs are a collection of clinical documents with free text information. These data are characterized by clinical terminologies and jargons specific to the repositories in which they were created. To use this kind of data for analytics requires understanding and developing approaches to translate these terminologies using natural language processing analysis. Equally devising taxonomies, particularly suitable for analytics, can help reduce data complexity and potentially accelerate development of decision support applications using the data from MyHR. Efforts to reduce complexity in data using taxonomies have been attempted in apps and wearable devices [
The second challenge relates to visualization and rendering of data sourced from MyHR. Results showed that a time-consuming work around was needed to meet the very prescriptive rendering guidelines needed to obtain conformance, even though the purpose of the application was to develop an alternative visualization of data. AI2 overcame this challenge by implementing both the default rendering and the new timeline visualization; however, developing the work around was time-consuming and ultimately did not contribute to the usefulness of the application. Relaxing the rendering guidelines would allow software developers to create new visualizations of data.
The ease of third-party application integration with MyHR system is another important factor in the development of secondary applications. Development with MyHR involves integration with 2 separate but interrelated services, which are coordinated by 2 different organizations. Medicare is responsible for the integration of user identity verification, and the Australian Digital Health Agency is responsible for the integration of provider identity verification. This dual verification process creates a complex workflow for application developers, particularly for startups and small businesses with limited resources. In addition, new applications have to be tested separately for an active connection and conformance to standards for each of these services. This complex process not only involves testing several elaborate scenarios, which may or may not be within the scope of the developed application, but also involves conducting these tests with 4 different teams. In this project, the time and resource allocated for meeting conformance requirements were substantially higher than was justified by the actual use cases. Although significant support is offered by the team at the Australian Digital Health Agency to help developers navigate the process, streamlining the testing process could actually reduce the time and costs for both application developers and the agency.
Streamlining integration and testing processes within MyHR will reduce the costs of third-party application development and reduce the time to market. It is more likely to create the impetus for an ecosystem of applications with innovative use cases of health data to emerge as it has for in the consumer wearables and health application spaces. Improvements to the way in which software developers can integrate and work with MyHR will ultimately both improve engagement with and generate value for MyHR. Finally, improving the size and richness of test data provided to application developers such that it reflects complete records of several patients can also assist in helping development of new applications.
Given the substantial investment by the Australian Government, and other governments worldwide, in developing National EHR system, MyHR system operators and other national EHR authorities are increasingly recognizing the value of innovative third-party applications in adding value for consumers by better engaging consumers in their own health care and for clinicians, through the addition of analytics to clinical portals. Innovative applications have a key role in realizing the initial vision for MyHR of improving health care outcomes and gaining efficiencies in the delivery of health care services. Consequently, it is important that the development environment facilitates rather than hinders third-party application development to attract and capitalize on research and entrepreneurial activities in this space.
Actionable Intime Insights application
application programming interface
Commonwealth
electronic health record
Healthcare Identifier verification service
Healthcare Provider Identifier
Individual Health Identifier
Medical Benefits Scheme
My Health Record
Notice of Connection
Prescription Benefit Scheme
NB is supported by funding from Country Health SA. The study was supported by grants from Country Health SA and Flinders ED IAPT service. The authors would like to acknowledge technical support and advise provided by staff at the Australian Digital Health Agency (formerly NEHTA) and the contributions of Mr Seoyong Lim and Yang Yang on this project for programming and testing the software application. The authors wish to acknowledge the Medical Research Futures Fund Rapid Applied Research Translation Program and Commonwealth Department of Health in supporting the aim to trial AI2 application with mental health patients.
NB designed and led the study, supervised software development, and wrote the full draft. YvK, PM, and MK contributed to the writing and revision of the paper.
None declared.