GP SOFTWARE VENDORS DISCUSS
POST PCEHR DEVELOPMENT ROADMAPS While the government considers the findings of the review into the PCEHR and decides upon its next course of action in relation to the system, GP software vendors are using the opportunity to consolidate the work they have done on the PCEHR, and revisit their other development priorities.
SIMON JAMES BIT, BComm Editor: Pulse+IT firstname.lastname@example.org
Development work on the PCEHR commenced in earnest with the formation of the GP vendor panel in 2011. The process, coordinated by the National E-Health Transition Authority (NEHTA), provided funding assistance and support to six clinical software development companies with a view to fast-tracking the rollout of PCEHR-enabled solutions to the general practice market. In the intervening years, these software developers, as well as several others not engaged in the GP vendor panel process, have built interfaces to not only the PCEHR, but some of its underlying foundations including the Healthcare Identifiers Service (HI Service). Despite the fact that many of these interfaces have largely been ignored by the clinicians the government intended to use them, the programming and refinement of PCEHR features in GP software has nevertheless consumed considerable development resources. As one software developer reported to Pulse+IT: “A lot of our resources have been dedicated to the initial release of the PCEHR. Now that that’s all been released, we are working on finalising the minor changes that need to be done, so we are now able to focus on other things that need to be done for our customers.”
Those minor changes relate to the Clinical Usability Program (CUP), which was established by NEHTA in response to criticism about some aspects of the PCEHR’s implementations within GP software. According to one software developer, the improvements suggested in the CUP process appear to be written in response to perceived problems in some of the software vendors’ initial PCEHR implementations. “I’m sure looking at some of the requirements of the CUP, it’s clear that they were based on some of the implementations of other software. It was clear that they looked at some other software and said ‘well, we need to fix this so we’ll put a requirement in for that’.” The extent to which the problems highlighted by the CUP process were significant enough to dissuade GPs from using the PCEHR functionality in their software has been challenged by several software developers, with some saying that the changes made the PCEHR interfaces less consistent with other parts of their program. Software vendors also reported that such issues stem from a desire by NEHTA to have each PCEHR interface in GP software