Vendors outline PCEHR-enabled software plans
This article first appeared in the May 2012 edition of Pulse+IT Magazine.
With funding support from government, a GP desktop software vendor panel was convened to incentivise software developers to create interfaces to the PCEHR, and in doing so, ensure practices will have access to PCEHR-enabled versions of their existing practice software.
The panel initially comprised Best Practice, iSOFT (now CSC’s Healthcare Group), Medtech Global and Zedmed. Genie Solutions and Communicare Systems were later added to the panel in reflection of their relevance in various Wave 2 pilot projects and their leading positions in the specialist and indigenous health software markets respectively.
Notably absent from this initial vendor cohort was Health Communication Network (HCN), however it is believed the dominant supplier of clinical software to Australian general practice has since been engaged by government to undertake a similar program of work to that of the vendor panel.
While many of the aforementioned software developers retail solutions to other parts of the health sector, for general practices particularly, the work of the vendor panel is of increasing importance. The federal government’s 2012-2013 budget has indicated that practices may be required to use PCEHR-enabled software to continue to access eHealth PIP payments from February 2013.
While this may cause some practices a measure of concern, it should be noted that previous eHealth and IT/IM PIP criteria have been anything but strongly worded. In fact if history serves as a useful guide, it may well eventuate that a vague ‘intention’ to interact with the PCEHR may qualify a practice for incentive payments, at least while the national record system is in a fledgling state.
Despite the uncertainty relating to general practice incentives and the shifting project arrangements software developers are having to navigate, it remains both prudent and timely for practices to start to increase their knowledge of the work being undertaken by their software supplier as it pertains to the Healthcare Identifier (HI) Service and the PCEHR.
In consultation with their software vendor and IT support professionals, it may be that organisations should consider upgrading to recent versions of their software with a view to better familiarising themselves with the currently included functionality in advance of the launch of additional PCEHR-specific functionality.
Best Practice released its HI Service functionality in version 220.127.116.115 in May this year. In addition to downloading IHIs on a per-patient basis, Best Practice will analyse future patient appointments and attempt to retrieve IHIs, allowing practice staff to check patient details for obvious errors in their demographic details before the patient presents.
As is the case with other software interacting with the HI Service, matching and downloading an IHI requires that a first name, last name, date of birth, and either a Medicare or DVA number be accurately recorded for the patient.
Best Practice CEO Frank Pyefinch used his concluding address at the Best Practice Summit, held in Bundaberg in March, to give conference delegates a glimpse of his product’s forthcoming HI Service and PCEHR functionality. Speaking to Pulse+IT at the event, Dr Pyefinch indicated that more features relating to the HI Service were planned in accordance with the vendor panel work program, including the ability for users of his company’s software to look up the HPI-Is and HPI-Os of other providers and organisations for the purpose of sending them secure electronic correspondence.
“HPI-Os are going to be the primary identifier for sending electronic mail to other people,” Dr Pyefinch said. “So if you want to send to a specialist, you would actually use the HPI-O of his clinic rather than his HPI-I. The reason is most medical practices these days have more than one person in them and if they go on holidays and you’ve addressed something to the HPI-I, then only that person can view it. Whereas if you address it to the organisation, other doctors can view it and determine who within the organisation should deal with the incoming correspondence.
“We have done the work to do it but ... it’s not live and it’s not connecting to the Medicare servers. At the moment users have to manually type them in.”
Describing how the HI Service HPI-O look-up will work when implemented, Dr Pyefinch said users can look up an organisation’s HPI based on the name of the organisation. “Unfortunately it has to be a pretty exact match.,” he said. “You need to know the formal name the organisation has registered with Medicare Australia, and if you do you should get the HPI-O back. For example if I type in ‘Millbank Medical Practice’, it may return a HPI-O but ‘Millbank Medical Clinic’ will not.”
Communicare Systems first made its HI Service functionality available last year in version 11.3, which allowed users of the software to download patient IHIs. More recently, version 11.4 added the ability for HPI-Is and HPI-Os to be recorded, which are necessary for interfacing with the PCEHR and likely to be important for future secure messaging between healthcare organisations and providers.
Heidi Tudehope of Communicare Systems indicated that the company’s work with healthcare identifiers is familiar to their users, many of whom were 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 is an easy transition for users,” Ms Tudehope said. “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.”
The company indicated it was in a strong position to deliver PCEHR functionality, pointing to its experiences with other shared record projects.
“While the PCEHR 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,” she said.
Asked if Communicare is advising customers to clean up their data in advance of the launch of the PCEHR, Ms Tudehope indicated that unlike many other healthcare organisations, Communicare’s users typically work in areas that mandate the use of coded clinical data, such as indigenous health clinics. This means that the quality of their data as far as the PCEHR is concerned will already be quite high and unambiguous.
CSC’s Healthcare Group
Recently acquired by CSC as part of its acquisition of iSOFT, a version of practiX containing HI Service functionality has been available for installation by practices since July 2011. At present, however, the company hasn’t deployed it to practices.
“We are currently working with our customer base to identify early adopter sites for this version of our software,” a CSC spokesperson said.
Discussing the way the company envisages the software will be used once their users start interacting with the HI Service, the spokesperson said, “We understand that many of the Wave sites are using batch methods for understanding the level of data quality, however we feel that obtaining the IHI upon presentation is the best method of locating the identifier.
“In an effort to maximise the number of matches that we receive for looking up an Individual Healthcare Identifier (IHI), we recommend the real-time lookup of an identifier, whilst the patient is presenting for care. In this way, changes in key information can be rectified to receive the patient’s IHI.”
As far as the development of broader PCEHR functionality and connectivity to the service is concerned, the spokesperson said, “CSC is currently in negotiation with NEHTA to amend our deliverables to provide a PCEHR B2B gateway-enabled version of practiX. We expect it to be finalised shortly and then development will commence on the required functionality.
“CSC understands that a CCA process will need to be performed to enable the PCEHR B2B gateway functionality within our product set. We have undertaken similar CCA processes for both the HI Service and Secure Message Delivery, and will undertake the PCEHR testing in the same manner, for our contracted delivery for NEHTA.”
Genie Solutions’ HI Service functionality started to emerge in version 8.2 in October 2011, providing users in some of the Wave pilot sites with the ability to download and verify patient IHIs, in addition to the ability to display discharge summaries and referral letters sent in CDA format. The functionality was extended to Genie’s broader user base with the release of Genie version 8.2.7 in March this year.
When asked about Genie’s progress developing functionality specific to the PCEHR, managing director Paul Carr indicated that his company has completed most of the development work required to upload both event summaries and shared health summaries, and will commence testing its interface to the PCEHR infrastructure soon to complete the CCA process.
“We’ve pretty much done all the groundwork now, so it’s just a matter of trialling it within NEHTA’s new test environment,” Dr Carr said.” I think our vendor panel deadline to deliver this functionality is end of October so things will progress in the coming months.”
In addition to the work Genie Solutions has been undertaking for the PCEHR, the company has also been working on similar shared record functionality as part of its involvement with Queensland's Mater Hospital, one of the Wave 2 sites.
“We’ve also completed work to enable obstetricians and gynaecologists to upload a pregnancy summary to the Mater Hospital in Brisbane as part of the Wave 2 project we’ve been involved with,” Dr Carr said. “This is basically the same thing as the PCEHR work we’ve undertaken, it just uses a slightly different interface but many of the same PCEHR specifications.
“The Mater has been testing it [recently] and everything is fine so they’re now about to roll it out at one of their users’ practices. Technically the functionality is already available more broadly but we’ve hidden it from the wider user base while the testing is being finalised.”
HCN, which counts more general practice customers than any other clinical software vendor in Australia, released HI Service functionality in January 2012 in Medical Director version 3.12.1b, making it available to all customers at that time.
When asked about PCEHR-specific functionality, a spokeswoman for HCN said the company does not pre-announce its product roadmaps, and was not able to be drawn about what future functionality it would release, and its expected timeframes for such releases. However, the spokeswoman did reaffirm the company’s interest in the PCEHR project, stating that “HCN is committed to Australia’s eHealth strategy and we will deliver those aspects that makes sense to and are a benefit to our customers.”
Medtech Global first released its initial HI Service functionality in late 2011 to support 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 patient records, providing a useful testing environment for both Medtech’s HI functionality and the HI Service itself.
Medtech32 version 8.1.2 was the first release of the software to include HI Service features, however Medtech Global's chief technology officer Rama Kumble indicated adoption of these parts of the product are subdued at the moment due to a lack of general awareness about the HI Service.
“We haven’t done a major push for the HI Service outside of the Wave sites, as our customers need to be properly educated about it before turning it on,” Mr Kumble said. “We believe NEHTA is putting together education campaign material in this regard which will help over time, however if a customer wants to adopt it now, they can contact us and patch their software to add the functionality.
“We’ve produced a reusable component and made only minimal changes to Medtech32. Nearly everything is in a component which we can pick up and use in other Medtech products, such as Medtech Evolution and Rx. Our development focus is now more geared towards the PCEHR and getting ready to deliver on our vendor panel commitments, such as reading a CDA document, publishing a shared health summary, publishing an events summary, and other things like that.
“The real value add by Medtech would be to provide practices and especially doctors innovative ways of making use PCEHR repository of documents for the benefit of the patient.”
Zedmed first released HI Service functionality in version 16 of its product in August last year, providing users with the ability to download patient IHIs both on an individual basis, and also in batches.
As with the other participants on the vendor panel, the company is waiting on additional specifications to be released by NEHTA before it can complete its development and testing of additional HI Service functionality, such as the ability to retrieve HPI-Os and HPI-Is directly from the HI Service for the sake of secure messaging with other healthcare organisations.
“We are working away and aim to finish our PCEHR functionality towards the end of June,” a Zedmed spokesperson said. “We are focusing on the shared health summary initially and connectivity to the PCEHR. We have access to the test environment and we can run calls against the PCEHR environment, but we can not do the corresponding CCA tests yet as they are not completely finalised.
“What we’re planning to do is put in place the functionality to allow doctors to use the PCEHR to their best extent, but not disrupt them in the process. For example, if no new medications are prescribed or only a basic antibiotic, we won’t channel them into screens that ask them to upload such information to the PCEHR. Ultimately it will be up to the doctor to decide how they interact with the system.”
The spokesperson said Zedmed did not believe that practices would need to take additional steps to prepare their data in advance of the launch of the PCEHR. “If doctors have good clinical records in place, they won’t need to do anything different with the PCEHR. Maintaining good records is part of a normal workflow and if you have these in place, there won’t be any problems.”
Posted in Australian eHealth