Was there any other capacity (hardware, software, infrastructure, etc) issue you’d like to comment on about this?

a. Lack of extra PC to carry out

Recalls & Reminders 1 1

b. Lack of room 1 1

c. Other 1 1 2

Summary and Conclusion for Practice Capacity

What has become clear in this examination is that capacity ‘limitations or barriers’ (spare computers, infrastructure, extra workforce) were only ‘perceived’ to be there. It validated the observation by the IT/IM Officer in Chapter Four, that its all ‘a lack of awareness’ rather than a reality. That existing capacity is enough to implement chronic disease information systems (at least in computerised practices, which across Australia number

more than 90%). This can be said to be the result of lack of software capacity training of practice champions and others in general.

It also provided clues as to the major contributions practice champions had in partnership with the Division IM/IT support/change agent in creating awareness regarding false expectations of capacity needs to introduce information systems to deal with chronic conditions as contended in the literature review.

Development and Implementation Cycle Construct

This section of the interview centred on the practical application (Development and implementation cycle) of the system highlighted in the emerging conceptual framework (Table 34). It covers the initial problem definition, system analysis and decision making process to the physical running of the system. For example, the initial problem definition included typically searching through the practice database for patients coded with the chronic condition being sought to ascertain their screening rate (in the case of Cervical Screening); sometimes searching for pertinent clinical tests performed, practice records of recalls and reminders, lab lists of results and paper records, among others. This information allowing the working out of ‘real’ (evidence) coverage rates in accordance to existing populations to clarify further development and shape of the system according to the outcomes of these analysis.

The systems analysis would then centre on fitting work process according to human capacity, goals, etc. Implementation in general meant the training, physical setup of software applications (i.e. recall and reminders), and continuous support over time.

Adoption, in the context of this study means the long term use of the system; and outcomes the measurement of success in achieving practice set goals.

Figure 34 - Development and Implementation Cycle

Interviewees, although they were well aware of the IT/IM Officer’s contribution at their practice were nonetheless explained the role of the ‘systems analyst/change agent’ within the context of the framework prior to being questioned. Their feedback on this stage of the framework revealed that the Division IT/IM Officer was involved as the system analyst in conjunction with other staff in all cases but one, where he was acknowledged as the sole analyst (Question 1, in Table 35). Of those eight cases, Practice managers were co-analysts in six cases. Nurses were co-analysts in four cases. The PM, IT/IM person and Nurse were co-analysts in two of those cases.

When asked if there were any other individuals at their practices capable of doing this analysis, six responded that there were not, and three that there were Question 2a, Table 35).

The interviews now turned to the issue of goals set for the system once the analysis was complete. In eight cases the system was expected to maximise screening rates, two of those also wanted to reach a percentage of females screened by a determined date (fox example, 80% of females tested within the year); and one that did not really set a goal for the system (Question 2b, Table 35).

At this point, they were asked how and who made the decision about these goals. Interviewees were solely responsible for these decisions in five cases, with the practice manager’s own decision in four and one by a GP Principal. In four occasions, there were at

least two decision makers; practice managers and GP Principals in three cases and practice manager and the nurse in another. One interviewee suggested there was a ‘whole team approach’ (Question 2c, Table 35).

Involvement in designing the system was the next issue tested. The Division IT/IM person was involved in eight out of nine cases, in partnership with the practice manager in most cases (n=5), the nurse in two other cases and one with a staff member (one on these included all three mentioned). One practice manager was shown as being the sole person responsible for designing the system at one practice. Significantly, no GPs were involved in the design process (Question 2d, Table 35).

The involvement of the practice champion was elicited at this stage; where results showed that they were involved in all cases, ranking ‘very much’ in seven cases and ‘somewhat’ in another two (Question 2e, Table 35).

Now the interview turned its attention to the role the Division (through its IT/IM support person) played in the design of the system. Interviewees’ responses suggested that the Division support person suggested a variety of models for consideration (n=5); as well as the encouragement of the nurse’s role (n=6) and lastly the encouragement of a ‘whole practice approach’ in four cases. Four interviewees recalled multiple scenarios being suggested (Question 2f, Table 35).

Figure 35 - System Analysis, Design and Involvement

System Analysis Design and involvement

1. Who did the system analysis at that time?