Towards the PCEHR: An update from the Vendor Panel

Introduction

In November 2010, the National E-Health Transition Authority (NEHTA) called for proposals from clinical software developers to support a series of eHealth pilot projects being undertaken by three then-Divisions, namely GP Partners in Queensland, Hunter Urban Division of General Practice, and the Melbourne East General Practice Network. Collectively know as Wave 1, these localities were selected to serve as regions where eHealth specifications could be tested in live settings by practices and other healthcare organisations, with a view to this process informing the development of the Personally Controlled Electronic Health Record (PCEHR) and ongoing eHealth specifications and standards development. Nine additional pilot projects have since been enacted under the Wave 2 initiative, however it is important to note that the work of the software developers detailed in this article has relevance and applicability that transcends both the Wave 1 and Wave 2 pilots, and indeed the PCEHR.

The Personally Controlled Electronic Health Record

While the terms used to describe the architecture vary depending on whether it’s being discussed by politicians or software developers, the PCEHR will ultimately manifest itself as a collection of repositories intended to allow information from various clinical systems to be aggregated together for the purpose of making this information readily accessible to healthcare providers across the sector. Patients will also have the ability to view and add information to ‘their’ PCEHR, however the extent to which this opportunity will be pursued by patients remains a point of contention.

With the National Infrastructure Partner — the consortia tasked with building the core PCEHR technology — only recently named and awarded funding, any attempt to detail what the PCEHR will look like in practical terms and how healthcare providers and patients will interact with it after its launch on 1st July 2012 would be somewhat speculative, notwithstanding the availability of the Draft Concept of Operations: Relating to the introduction of a personally controlled electronic health record system and the PCEHR System: Legislation Issues Paper. Over 160 submissions were received in response to the first document, which is scheduled to be finalised and made public in September.

Announced in August, the National Infrastructure Partner consortia includes Accenture, Oracle, Orion Health and Telstra, who have been awarded a total of $77m to undertake their program of work.

In announcing the winners of the tender process, Minister for Health and Ageing, Nicola Roxon, cited the group’s collective experience in Singapore as a major factor in their selection, referring to the fact that members of this consortia had built and ‘gone live’ with the first phase of the Singapore National Electronic Health Record in June this year.

While much of the underlying technology used in the Singapore project is likely to emerge as the basis of Australia’s core PCEHR infrastructure, Brad Cable, Accenture’s Australian Health and Public Service lead, acknowledged the differences between the Singaporean and Australian health sectors and the countries’ ambitions for their respective health record projects.

“The health industry in Singapore is certainly a lot different to the one in Australia. What we are doing in Australia is utilising our experience from Singapore, plus some other electronic health records projects we have been involved in globally. We’ll be using similar products in Australia, but again, using them in the context of what Australia wants to deliver, being a Personally Controlled Electronic Health Record.

“Oracle and Orion Health will provide fundamental products for this project, and these are what we use globally as well. Accenture also has significant software assets ourselves, which bring all these pieces of technology together. Whilst principally we use the same basis, the health sectors are all slightly different in the way they approach it, the way they implement it, with different clinical software packages feeding the health records to consider as well. Conceptually the same, but they are all unique and have their differences,” said Mr Cable.

The Vendor Panel

As the National Infrastructure Partner works on the mammoth task it has been assigned, what will be more immediately relevant to clinicians and the people working with them in private practice settings is the project being undertaken by the Vendor Panel. This group is made up of six software companies tasked and funded by Government to incorporate specific pieces of functionality into their clinical software, with some parcels of development already completed.

The initial Vendor Panel comprised of Best Practice, iSoft, Medtech Global and Zedmed. Two additional vendors, Genie Solutions and Communicare Systems were added to the Vendor Panel after its initial formation, purportedly in reflection of the fact that customers of these companies were expected to be important to the viability of several Wave 2 pilot projects.

Scope of Work

The work being undertaken by members of the Vendor Panel has been divided into three project milestones, imaginatively named Release 1, 2 and 3. The priority order of the pieces of development within these Releases has allowed some of the early software enhancements to be piloted by practices located within the Wave 1 geographic catchments, however only minimal details about the rollout of these enhancements have started to emerge.

Release 1

Healthcare Identifiers

The first component of Release 1 requires that healthcare identifier functionality be incorporated into the vendors’ clinical software. In broad terms, the widespread adoption of healthcare identifiers is intended to allow clinical software to more reliably match electronic correspondence, minimising the risk of clinical information being misfiled and overlooked.

There are three types of healthcare identifiers associated with the project, namely:

  • Individual Healthcare Identifiers (IHI)
  • Healthcare Provider Identifiers for Individuals (HPI-I)
  • Healthcare Provider Identifiers for Organisations (HPI-O)

Given the serious patient safety consequences that may ensue in the event of a mismatched clinical document, software developers are required to submit to two levels of third-party testing before they can interact with the Medicare Australia‑run Healthcare Identifier Service.

The first, dubbed the ‘Notice of Connectivity’ is designed to test basic communication between a clinical software package and the Healthcare Identifier Service. Dr Frank Pyefinch of Best Practice Software described this process as “quite simple”, notwithstanding the few days that were required to work through the various testing scenarios.

A more rigorous and costly testing process overseen by the National Association of Testing Authorities (NATA) is also required to be undertaken by software developers looking to interface their solutions with the Healthcare Identifier Service. This process, performed by a NATA accredited testing laboratory, requires the software developer to hand over their software to be functionally tested, a process that takes around five to seven days according to most of the vendors on the panel. During this process, the testing laboratories were required to perform over 100 practical tests to ensure the clinical software safely and appropriately handles any interaction the software has with the Healthcare Identifier Service or healthcare identifiers stored within the software.

Clinical Document Architecture

The second parcel of work within Release 1 requires members of the Vendor Panel to enable their software to display electronic Discharge Summaries and Specialist Letters. While most modern Australian clinical software can already display incoming electronic correspondence, much of this existing functionality is built upon the HL7 v2 standard and not the Clinical Document Architecture (CDA) specifications being advocated by NEHTA.

In a logical combining of the aforementioned healthcare identifier functionality and the required CDA capabilities, the vendors’ software needs to be able to match incoming CDA documents to the appropriate patient and clinician using the Healthcare Identifiers embedded in the CDA message.

The deadlines for the delivery of the Release 1 work has now passed, with all six Vendor Panel members having successfully completed the requisite development.

Release 2

To be delivered by the end of October, Vendor Panel members are required to enhance their software to allow it to generate Electronic Referrals and Health Summaries in CDA format, and then transfer these using a Secure Message Delivery (SMD) carrier. For a comprehensive overview of SMD, see [Pulse+IT Magazine, July 2010, pp20], however in essence, the technology is designed to allow secure messages to be sent from one clinical software package to another, regardless of which messaging capability the sender and receiver have selected. Secure messaging solutions are plentiful in Australia, however few if any are compatible with offerings from competing vendors, effectively requiring that both the sender and receiver of secure electronic correspondence are using the same system.

While the intent of the SMD initiative is laudable, there are several pieces of infrastructure that have not yet emerged, the ongoing absence of which would stifle any large scale attempt for messages to be sent between competing messaging carriers using SMD. However notwithstanding the need for the ongoing development of shared SMD infrastructure components, the funding of CDA development for Electronic Referrals should remove many of the electronic clinical document compatibility issues that have hampered adoption, particularly by general practice, the vast majority of whom do not generate Electronic Referrals.

The Health Summaries produced by the software are ultimately intended to be passed along to the PCEHR, however such documents could just as easily be sent to other healthcare providers directly. These summaries would typically contain information about allergies, medications, demographics, adverse drug reactions, immunisations, pathology results, and a past history list.

Release 3

Intended for completion in early 2012, Release 3 requires that Vendor Panel members deploy a range of functionality, namely the Australian Medicines Terminology (AMT), SNOMED CT, Event Summaries, and Electronic Transfer of Prescription features. With Vendor Panel members mostly consumed with the requirements of Release 2 at this time, few had turned their attention to the specifics of Release 3, limiting the amount of available information about the specific requirements of this final project stage.

Funding

To defray some of the development and deployment costs associated with the work being undertaken by the Vendor Panel, members are to receive fixed price payments varying from around $15,000 to $30,000 for each of the various pieces of functionality described above. In addition, per site payments for each healthcare organisation that deploys software containing the updated functionality will also be made to the corresponding member of the Vendor Panel, however it is unclear whether such payments will apply only to healthcare organisations within the Wave 1 geographic catchments, or additionally include healthcare organisations operating in the Wave 2 localities.

A ‘sign-on bonus’ has also been afforded to members of the Vendor Panel, presumably to subsidise the costs associated with the collaborative process members of the panel are contractually required to undertake.

Updates from the Members

With the Release 1 deadline now passed and with all software developers on the panel working on Release 2, interviews with the companies involved have yielded the following progress updates. Note that due to space restrictions and the similarities between the work being undertaken by each vendor, only a small selection of each vendor’s progress has been highlighted in this article.

Best Practice

As a result of the Release 1 development work, Best Practice users will soon be able to download and verify patient IHI’s from the Healthcare Identifier Service from the demographics screen in the software. As will be the case with other clinical software, this feature requires that a first name, last name, date of birth, and either a Medicare or DVA number be accurately recorded for the patient.

While it is technically possible for a patient’s address to be used in the matching process, the wide variety of ways to record an address has meant some vendors, including Best Practice under advice from NEHTA, have steered away from this approach to matching at this time.

Best Practice has allowed users of its software to easily check if patients displayed on the appointment screen have valid healthcare identifiers stored in the Best Practice database. If they do, a green flag will be shown adjacent to the patient’s name, and if not, a red flag will be displayed. In the event of a patient having a red flag next to their name, the receptionist would endeavour to check the key demographics for the patient and subsequently download the patient’s valid healthcare identifier into the Best Practice database.

In support of the Wave 1 initiative — a part of which involves the large‑scale importation of healthcare identifiers into clinical software — Best Practice worked with Health Industry Exchange to allow its ‘HIE Sync’ software to perform batch lookups of healthcare identifiers in Wave 1 sites using Best Practice.

Communicare Systems

Customers of Communicare Systems will first have access to functionality developed as part of the Vendor Panel process with the impending release of v11.3. This build of the software is intended as a general release for all Communicare customers and will feature additional enhancements not directly related to healthcare identifiers and CDA.

Heidi Tudehope of Communicare Systems indicated that the company’s work with the Healthcare Identifier Service will be familiar to users, many of whom are using the somewhat similar Medicare Online Patient Verification features of the product.

“In a lot of ways we’ve mimicked the user functionality that we already had for referencing Medicare numbers so that it will be an easy transition for users. In the same way as we have developed our existing Medicare Online functionality, we display colour coding over the healthcare identifier number to indicate whether it has been validated or not,” said Ms Tudehope.

The work associated with later Releases of the Vendor Panel project will not be unfamiliar to Communicare Systems, the company having already participated in a range of shared electronic health records initiatives.

“While the deliverables for the Vendor Panel are not in the same format exactly, we already do a similar thing with the Northern Territory Shared Electronic Health Record and another shared record product called RecordPoint, developed by Extensia,” said Ms Tudehope.

Genie Solutions

Genie Solutions received notice that the healthcare identifier components of its software had been successfully tested in mid-August. As the company produces software for both Apple Macintosh and Microsoft Windows operating systems, independent testing was necessary for both versions of the software.

With the healthcare identifier functionality now complete, users of the software will have the option to download or verify healthcare identifiers from within the patient demographics screen. A date field and colour coding system has been incorporated to indicate the amount of time that has elapsed since the last verification has taken place.

Dr Paul Carr of Genie Solutions indicated that his company’s software will be rolled out to users of Genie v8 within the Wave 1 catchment, but this will expand over time as part of the existing rollout the company is undertaking with the latest version of its software.

Genie has long had the ability to display CDA messages, the functionality having been added to the software in response to previous NEHTA initiatives.

iSoft

Due to the large number of products developed by iSoft that will need to interact with the healthcare identifier service, Byron Phillips indicated that his company’s approach to the Vendor Panel has been mindful of the need to ensure any code produced can be utilised throughout a range of iSoft products.

“One of the things we’re reasonably proud of is that we were first to be certified through the third party independent labs. We were first to market with the enablement of our GP product, which is nice. The reason, partially, for that is we’ve always maintained that we would do this development as external to the applications as we can, so that we can reuse it, not just across our GP platforms, but our patient systems, our ED systems, our clinical systems, our pharmacy systems and so on. However it was the first test where we had to put something on the ground and get it independently tested,” said Mr Phillips.

iSoft has indicated that they are applying this approach to their work with SMD.

“Again, that’s a component that we’re building agnostic of the application, which is really important to us. We have a large set of applications in the acute market that we obviously need to have enabled through a similar approach.”

Medtech Global

Having completed the development work associated with Release 1, Medtech Global has been testing its healthcare identifier functionality in a selection of the clinics using its software in the Wave 1 geographic regions. Notably, one such healthcare facility in the Hunter Region of NSW has a database with over 250,000 patients.

Reflecting on his company’s range of clinical products, Rama Kumble of Medtech Global noted that a conscious decision was made to develop the requisite healthcare identifier functionality as an independent module.

“We’ve produced a reusable component. We’ve made only minimal changes to MedTech32 and nearly everything is in a component which we can pick up and use in other MedTech products, such as MedTech Evolution and Rx,” said Mr Kumble.

Zedmed

Zedmed users will be able to interact with the Healthcare Identifier Service once they have upgraded to v16. This version was made available to all practices running Zedmed in late August, with Dr Andrew Pascoe, Zedmed’s Clinical Lead, highlighting the important role healthcare identifiers will play in connecting healthcare organisations electronically.

“The introduction of HI’s is one of the first steps toward achieving a comprehensive approach to eHealth. GPs need software capable of delivering this seamless communication of reliable healthcare information between individuals, healthcare providers and other provider organisations. We have a solution that is ready and available in the market right now,” said Dr Pascoe.

According to Simonne Norton of Zedmed, a subsequent release of the software (v17) will follow in October, which is expected to incorporate the additional features being developed by the company as part of Release 2.

Conclusion

With the support of NEHTA, members on the Vendor Panel are charged with delivering a large parcel of software development in a very aggressive time frame. In fact many members on the Vendor Panel have indicated that other, more customer-centric development priorities have had to be put on hold to meet the agreed contractual deadlines of the process.

However despite the additional workload being undertaken, it is evident that there is acceptance of the process by members of the panel, and a belief in the benefits the project will yield as specifications and standards are rolled out in mainstream Australian clinical software. Summarising this sentiment are the words of a Vendor Panel member: "This whole project is about putting NEHTA’s work into some actual real life applications. Until Government decided to pay to have it done there was no real incentive for any of the vendors to actually do it. It was a lot of work and users weren’t crying out for it, and to be honest, everyone had pretty much come up with ways to get it done anyway. Pathology, radiology and discharge summaries have been flowing between hospital and doctors and labs for years, so there was no huge imperative to get some of these NEHTA specifications in place because they weren’t really going to add anything to the functionality that users had already. But, at the end of the day, they make it all a hell of a lot easier and a lot more standardised, which, from our point of view, will be good in the long term."

Posted in Australian eHealth

Comments   

# Blake Mumford 2012-07-08 04:47
Thank-you for the well written and comprehensive overview.

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.