Note: Where available, the PDF/Word icon below is provided to view the complete and fully formatted document
Computing facilities and systems for Health Services in the Australian Capital Territory - Report of the Computer Services Planning Committee, April 1974


Download PDF Download PDF

THE PARLIAMENT OF THE COMMONWEALTH OF AUSTRALIA

1975— Parliamentary Paper No. 41

REPORT OF THE COMPUTER SERVICES PLANNING COMMITTEE ON

THE PROVISIONS OF COMPUTING FACILITIES AND SYSTEMS FOR HEALTH SERVICES IN THE AUSTRALIAN CAPITAL TERRITORY

APRIL 1974

Presented by Command 25 February 1975

Ordered to be printed 6 March 1975

THE GOVERNMENT PRINTER OF AUSTRALIA

CANBERRA 1975

© Commonwealth of Australia 1974

Printed at The Dominion Press, North Blackburn, Victoria

The Hon. D. N. Everingham, M.P. Minister for Health Parliament House Canberra.

The Computer Services Planning Committee, which you established to advise you on the computing services and facilities appropriate to the Capital Territory Health Commission, has completed its deliberations. I have pleasure in submitting the Committee’s final Report for your consideration.

Gwyn Howells Director-General of Health April 1974 Canberra, A.C.T.

CONTENTS

1 Introduction

2 Environmental background to Committee’s deliberations

3 Recommendations of the Computer Services Planning Committee

4 Developments in health care in Australia and abroad 4.1 Introduction 4.2 United States of America 4.3 England

4.4 Sweden 4.5 Other countries 4.6 Summary of overseas developments 4.7 Developments in Australia 4.7.1 Australian Department of Health

4.7.2 Australian Department of Repatriation 4.7.3 New South Wales 4.7.4 Victoria

4.7.5 Queensland 4.7.6 South Australia 4.7.7 Western Australia 4.7.8 Tasmania

4.7.9 HASAC—Computer Committee

5 The computing needs of the Capital Territory Health Commission 5.1 Computing needs at commencement of Commission activities 5.2 Areas of potential need and future development 5.3 Criteria influencing the allocation of priorities

(a) Cost benefit analysis (b) Availability of resources (c) Implementation timetable (d) Probability of success

(e) Relationship to existing systems (f) Availability of existing software (g) Furtherance of Commission policies (h) Projects of national significance 5.4 Definition of priorities

5.5 Assignment of priorities

6 Computer-based medical records 6.1 General considerations 6.2 Patient identification and record linkage 6.3 The privacy issue

7 Resource requirements 7.1 Introduction 7.2 Computer hardware

Chapter

v

Chapter

7.3 7.4 7.5 7.5.1

7.5.2 7.5.3

8 8.1 8.2 8.3 8.4 8.5 8.5.1 8.5.2 8.5.3

8.5.4 8.5.5 8.5.6 8.5.7 8.5.8 8.5.9 8.6 8.7 8.7.1 8.7.2 8.7.3 8.7.4 8.7.5 8.7.6

9 9.1 9.2

9.3 9.4

9.5

Computer software Computer accommodation Computer staff requirements Senior computer management

Programming staff Other staff

Provision of resources Introduction Interim facilities appropriate to initial operation of the Commission Interim facilities for developmental work Preservation of options Commission facilities

General considerations Hardware acquisition Relationship with Australian Government Stores and Tender . Board

Relationship with the Interdepartmental Committee on ADP Multiple suppliers Systems of differing size and functional use Cost of equipment Equipment maintenance Software acquisition Accommodation for Commission facilities Technical personnel

Initial staff acquisition Consultants and contract programmers Computer operations staff Trainee programmers Ancillary support staff Steering Committee

Strategic aspects of installation and system planning General considerations Reliability of the system (a) Transient or momentary failures

(b) Failure of a peripheral component (c) Failure of entire system (d) Catastrophes Security of information Accuracy of computation

(a) Undetected transmission errors (b) Errors in data submitted to the system (c) Errors in transferring data from CPU to storage device (d) Program errors

Summary

vi

10 Training 10.1 Introduction 10.2 Planning 10.3 Training and staff involvement

10.4 Public relations 10.5 Conclusions

11 Summary of Committee’s activities

Chapter

vii

APPENDIXES

Appendix

1 Computer Services Planning Committee Terms of Reference

2 A list of meetings of the Computer Services Planning Committee and its Working Parties Committee meeting dates and main topics Working Party meetings

3 Composition of Working Parties to the Computer Services Planning Committee Working Party 1 (T.R.l) Working Party 2 (T.R.2 and T.R.3)

Working Party 3 (T.R.7 and T.R.8) Working Party 4 (T.R.4 and T.R.6) Working Party 5 (T.R.5)

4 Visits undertaken by the Computer Services Planning Committee

5 Medical record linkage—an evolutionary approach Introduction Issues of privacy and community acceptance Patient identification

Definition of terminology Decentralised Medical Record Linkage Centralised Medical Record Linkage The Integrated Patient Record Data Base

Conclusions

6 HASAC personal identification key—Electoral Roll analysis

7 Review of possible areas of computer application within the A.C.T. Health Care environment Ad hoc research projects Ambulance services

Analysis of ECG recordings Automated history taking Blood Bank Child health Clinical laboratories

Clinical service departments '

Commercial systems Computer-aided diagnosis District nursing Food services

General communications Health care activity analysis Health centres

Appendix

7 (continued) Inpatient management Intensive care monitoring Library services

Medical records . Mental health services Nurse rostering Nursing homes Nursing orders Office services Operational research and Ο & M

Patient billing Patient scheduling Pharmacy Physiological monitoring/measurement Preadmissions Preventive health care ,

Private health facilities Registration boards Supply Surgery Systems training

8 Table showing range of possible applications and criteria influencing the allocation of priorities by Committee

9 Minimum system characteristics required to meet needs of ‘Monash' system General information Minimum hardware characteristics Software characteristics Operating requirements

10 Criteria for evaluating suitability of software packages

Current operational status Proven use in other organisations Practicability and usefulness Assessment of the applicability of the package in the

Australian environment and especially the Australian Capital Territory Availability of the package Cost of obtaining and implementing the package Support of the package by the supplier

Maintainability Cost of operation Cost of future development

Appendix ■

10 (continued)

Impact of the package on overall strategic design for development Hardware implications

Glossary of terms

Bibliography A.C.T. Health Care Delivery Environment Hospital and Health Care Systems (General) Confidentiality

Medical Records and Record Linkage Laboratory Systems . Automated History Taking Computer-aided Diagnosis

Inpatient Management and Resource Scheduling Pharmacy Systems ECG Analysis Food Services

Patient Monitoring

CHAPTER 1—INTRODUCTION

1.1 Public responsibility for health care delivery and administration in the Aus­ tralian Capital Territory is vested in the Australian Minister for Health. Both Canberra Hospital and Woden Hospital are administered under ordinance by the Canberra Hospitals Management Board comprising a number of representatives

appointed by the Minister, including two nominees of the A.C.T. Advisory Coun­ cil. Other aspects of health care delivery which fall within the public domain are administered by the A.C.T. Health Services Division of the Australian Department

of Health. The Division reports to the Minister through the Director-General of Health.

1.2 The division of responsibility between the two authorities is the subject of present attention. The Government’s announced intention is to place all relevant matters relating to health care administration and health care delivery in the A.C.T. under the control of a Capital Territory Health Commission.

1.3 Early in 1971 the Canberra Hospital Board authorised the commencement of investigations into the use of computer systems in certain areas of hospital accounting. As a result of these investigations steps were taken by the Board to obtain access to computing systems developed by the Computer Study Group of

the Hospitals and Charities Commission in Victoria. In the main these systems covered such areas as Pay and Personnel, Creditors/General Ledger, etc. In the light of this development and the Board’s intention to extend the initial arrange­ ment to encompass further areas of hospital activity, it was suggested in November

1972 that the extended arrangement which the Board envisaged might be held over pending the outcome of a technically-based investigation which would encom­ pass, inter alia'.

the determination of need across each of the several hospital functional activities;

a clear assessment of the resources and procedures which it is proposed would satisfy these needs;

a specification of priorities for implementation;

the determination of plans and procedures and the formulation of appropriate recommendations covering acquisition of the dedicated support, in terms of equipment and technical personnel, which are essential to systems development and operation;

the determination of appropriate training procedures covering the relevant activities of all personnel who will relate to the system; and

the formulation of appropriate fail-back arrangements which recognised the special needs of systems availability in the hospital environment and which distinguish it from many other applications in the data processing area.

1.4 Dr Everingham, the Minister for Health, wrote to the Chairman of the Can­ berra Hospital Board on 21 February 1973 on this matter. He requested that the Board refrain from further developments in the computing field until the total

1

question of computers in the A.C.T. health care environment had been examined by an expert Study Group. He pointed out, however, that he did not wish termi­ nation of any undertaking so far made by the Management of either hospital to result in a breach of faith.

1.5 In a subsequent letter to the Chairman of the Hospital Board the Minister established the Computer Services Planning Committee. He indicated that the Committee’s Terms of Reference were sufficiently broad to allow systems which had been the subject of prior arrangement by the Hospital Management Board to be reviewed in the light of medium term requirements in the context of future ADP systems development. The Chairman agreed that the Board should not enter into any new arrangement in the computing field pending the Committee’s advice to the Minister.

1.6 On 2 August 1973 representatives from selected organizations were invited by the Department to join the Computer Services Planning Committee. The Commit­ tee was, in general terms, charged with the responsibility to advise the Minister, pending the establishment of the Capital Territory Health Commission, upon the computing services necessary for the Commission. The specific Terms of Reference are set out in Appendix 1.

1.7 Membership of the Committee, as established, was:

Mr R. H. Searle, Chairman Assistant Director-General, ADP Branch. Department of Health, Canberra.

Director (Applications), ADP Branch, Department of Health, Canberra.

General Superintendent, Woden Valley Hospital.

Assistant Director-General (ADP), Department of Social Security, Canberra.

Medical Advisory Committee, Canberra Hospital.

Assistant Director, A.C.T. Health Services, Canberra.

General Superintendent, Canberra Hospital.

Assistant Commissioner (ADP), General Developments Branch, Public Service Board, Canberra.

Assistant Commissioner (ADP), Repatriation Department, Canberra.

1.8 Mr J. B. Kelly, Assistant Secretary, Woden Valley Hospital, was appointed as Secretary to the Committee. Other support for fact-finding, participation in . Working Party tasks and other necessary studies was provided by the secondment of Mr Η. B. Miller, Assistant Director, and Mr R. D. Wadrop, Senior Program­

mer, from Department of Health.

Mr J. G. Burt

Dr N. A. Elvin

Mr D. A. Harragan

Dr F. Lomas

Mr B. V. McKay

Dr T. A. Sale

Mr J. W. Shaw

Mr A. Usher

2

1.9 Dr F. Lomas was appointed to replace the initial Medical Advisory Commit­ tee nominee Dr McCuaig, who had found that his prior commitments would pre­ vent his full participation on Committee.

1.10 Other particular assistance was provided by Mr R. Gordon, Secretary, Woden Valley Hospital and Mr A. Tozer, Secretary, Canberra Hospital, Mrs A. Kern, Mr W. Bruen and Mr I. Peterson of the A.C.T. Health Services Division. The ready co-operation which was obtained from all people who were approached

on relevant matters was appreciated by Committee. A number of institutions, set out in Appendix 4, were also helpful in providing informative visits and demon­ strations for the Committee.

1.11 At the initial Meeting of the Computer Services Planning Committee, held on 21 August 1973, an overall strategy was planned to meet the task which had been set by the Minister. It was agreed to consider as a matter of urgency the

immediate requirements of the proposed Health Commission (Term of Reference No. 1) with a view to issuing an Interim Report to the Minister for Health on this aspect for his consideration. The general line was taken that a number of Working Parties should be established, comprising both Committee members and personnel

experienced in particular areas of concern. The Reports of these Working Parties and other background papers considered by Committee are available for perusal if required, together with the Committee’s findings and conclusions, where appropri­ ate. It was recognised that wide exposure to health care systems and supporting computer installations had to be obtained and that wherever possible the views

being formulated by Committee should be tested against the opinions and experi­ ence of experts working in the health care field.

1.12 The Interim Report was duly provided and its recommendations accepted and approved by the Minister for Health on 2 February 1974. For completeness, the findings of the Committee expressed in the Interim Report have been included in this Final Report. However, the Interim Report is available for perusal as a

separate document.

3

CHAPTER 2—ENVIRONMENTAL BACKGROUND TO COMMITTEE’S DELIBERATIONS

2.1 At first sight the timing of the Committee’s investigations might appear something less than propitious, coinciding as it has with a period of innovation and metamorphosis in the shape of health care delivery and administration in the A.C.T. Moves towards diversification and decentralisation of health care delivery outlets accompanied by centralisation of many administrative and support func­ tions will undoubtedly influence the precise nature of computing facilities which might be established to sustain and promote the activities of the Capital Territory Health Commission. On the other hand, however, the changing nature of the environment has enabled Committee to concentrate its attention on the functional aspects of health care delivery without being unduly encumbered by administrative and organisational complexities which might otherwise have intruded on its con­ siderations. The functional approach which pervades this report has permitted a broader perspective of the total scene and concentration on the major issues of need for and development of computer support. Committee has attempted to avoid encroaching on matters of detail where decisions should properly remain the re­ sponsibility of Commission staff.

2.2 Notwithstanding the absence of a definitive organisational structure, Com­ mittee’s considerations have been premised on a broad picture of the shape of the health care delivery system in terms of the patient’s relationship with its vari­ ous sectors. The patient as the consumer is presented with a large variety of

delivery outlets. Many of these, particularly within the private sector, provide the individual with the ability to choose between a number of functionally similar nodes; in other areas the consumer’s choice is more restricted. However, the analogy with the day to day marketing environment breaks down when one con­ siders the degree of interdependence among component parts of the health distri­ butive network. In this context each node in the health care delivery network, whether it be entrepreneurial in character, embodied within the public sector or a mixture of both, must have as its first consideration the health and well-being of the patient. This can best be advanced by a co-operative and co-ordinated approach. The Llewelyn-Davies Report (see Bibliography) observes, ‘No one part of health care services can operate in isolation, and a prerequisite for success lies in the linking of disparate branches of the system, whether private or public’.

2.3 The Committee endorses this view but sees it as a material departure from the traditional concepts of private medicine on the one hand and independent institutional care on the other. This trend, already evident overseas and manifest­ ing itself in the establishment of community health centres in the A.C.T., can only be fully realised by erecting a reliable and responsive foundation for the flow of relevant clinical and administrative information between participating nodes. It is unlikely that this goal can be completely attained without recourse to computer support. Areas such as the need to compile patients’ medical histories

and to accurately, rapidly and confidentially distribute pertinent information as required within the network; the need to aggregate, analyse and present data to

4

support ongoing evaluation and monitoring of the health service as a whole or of individual programs in particular; the need to co-ordinate and rationalise the distribution of health care resources according to community needs; the need to maximise the level of care available to the patient at minimum inconvenience by

optimal scheduling of resources; all these requirements, and others, point strongly to the need for computer support. The Committee recognized that within the bounds of good medical, nursing and paramedical practice, these requirements should be met within the broad context of voluntary participation by the individual. This factor, combined with the Government’s expressed intention to develop the

A.C.T. as a ‘model’ for regional health support systems lends weight to the argu­ ment that computer support is a necessary adjunct to efficient and effective health care delivery. The general conclusion drawn by the Committee is that the Com­ mission requires a potentially powerful centralised computing facility, which is

supported and complemented by mini-computer units where these are more appro­ priate to specific functions.

2.4 The Committee sees strong evidence to support the introduction of computer- based systems in the A.C.T. health care delivery field. A wide range of applications has been identified and these applications are discussed later in this report. It has also become apparent that the nature of many of the more important applications,

involving on-line servicing of time-critical functions and the handling of confiden­ tial patient-oriented information will require that computing facilities be estab­ lished under the control of the Commission. Whereas reliance on alternative facilities for the servicing of a number of (mainly non-clinical) functions is per­ fectly feasible and indeed advocated by Committee for the short term, the service

bureau environment does not, on the whole, appear to be an appropriate one. On this basis and in the light of overseas developments, the ultimate achievement of processing self sufficiency for the Commission underlies the Committee’s findings

and its recommendations.

2.5 Progress throughout the world towards the development of a fully integrated health care system (that is, a system with a co-ordinated multi-functional approach) has not been as rapid as had been anticipated. Little evidence exists to suggest that this goal has yet been satisfactorily attained in anything but an experimental

environment. Whilst the objective of a fully integrated system is a laudable one, it should be recognised as a longer-term goal influencing the overall strategy of a more gradually phased approach. Both equipment procurement and system speci­ fication should therefore be viewed in the longer term context of expansion and

should be modular in form and capable of growth. Due consideration should be given to the dynamic and evolutionary nature of the health care service as a whole, with newly emerging techniques, shifts of emphasis between different dis­ ciplines, procedural changes and administrative restructuring. The application of computer technology backed by a flexible and far-sighted approach can provide

a robust framework with which to meet this challenge.

5

CHAPTER 3—RECOMMENDATIONS OF THE COMPUTER SERVICES PLANNING COMMITTEE

As a result of Committee deliberations and in accordance with Terms of Refer­ ence provided, the recommendations set out hereunder are made to the Aus­ tralian Minister for Health.

Location of the Recommendations in this Chapter of the Report is intended to provide a ready appreciation of the Committee’s findings and conclusions. How­ ever, these recommendations should be considered in the context of the relevant material contained in the body of the Report. Appropriate references are shown after each recommendation to facilitate ready access.

3.1 Recommendation: that appropriate steps be taken to meet the limited computer services essential for initial operation of the Commission.

(N.B. Due to the urgency attached to this matter, Committee provided an Interim Report to the Minister for Health. The Interim Report was approved by the Minister on 2 February, 1974. The recommendations of the Interim Report are repeated hereunder and augmented with further advice on this matter.)

3.1.1 Selected program facilities developed by the computer study group of the Victorian Hospitals and Charities Commission to service the areas identified in the Interim Report should be installed as soon as practicable into the relevant areas of activity proposed for the Capital Territory Health Commission. General installation before July, 1974 is seen as highly desirable. (Interim Report)

3.1.2 Arrangements should be made for future conversion of the systems referred to in the Interim Report for operation on a Canberra-based computing facility administered and operated by the Australian Government or one of its agencies. (Interim Report)

3.1.3 The conversion task referred to in 3.1.2 above should be initiated as soon as practicable. Nevertheless, introduction of any ‘converted’ system should not take place until after the ‘Monash’ equivalent is firmly established and functioning satisfactorily across appropriate areas in the Commission. (Interim Report)

(The characteristics of a computing installation appropriate to this initial computing service are set out in Appendix 9.)

3.1.4 The Commission should seek access to computing facilities in Canberra having the characteristics identified as suitable to meet its initial requirements. ( 8.2 . 1)

3.1.5 The Commission should approach the selected departments nominated in the Report in relation to the availability of facilities and support for the converted systems referred to above (8.2.1). An initial approach to the Department of Health for this purpose might receive consideration by the Commission (8.2.2). Evaluation of responses to any request by the Commission in this matter should receive particular attention regarding the terms under which facilities can be made available. (8.2.3)

6

3.2 Recommendation: the Commission must clearly define its priorities for ADP resource acquisition, systems study and development. Accordingly:

3.2.1 Initial priorities for study and development should be assigned by the Commission. (5.5.3)

{N.B. The Committee has identified criteria which it considers pertinent to the allocation of these priorities (5.3, 5.4). Section 5.5 covers the assignment of priorities to potential applications according to these criteria.)

3.2.2 Steps should be initiated to establish an appropriate environment con­ ducive to achieving the benefits of medical record linkage in the Australian Capital Territory. Progress towards a full system should be constrained within prevailing public standards, subject to informed public inspection and comment and con­

sistent with a high quality of individual health care and medical treatment. Full medical record linkage should, however, be regarded as a long-term goal attain­ able in stages rather than an immediate objective. (6.1.1, 6.1.2, 6.3.3, 6.3.4)

3.2.3 The Commission should, in its planning, take account of the longer term objective of the Government to establish a national system of voluntary computer- based linked medical records. (6.2.7)

3.2.4 However, the uniform system of personal identification recommended by the Hospital and Allied Services Advisory Council should be introduced in the Australian Capital Territory as soon as possible. (6.2.4)

3.3 Recommendation: the Commission should obtain and develop its own central computing facilities and accordingly:

3.3.1 The Commission should meet its initial developmental needs by:

3.3.1.1 Approaching selected departments nominated in the body of the Report with a view to obtaining access for the purposes of batch and on-line systems development and training initiated prior to the establishment of the

Commission’s own facilities. Advantages would accrue to the Commission if facilities for production and developmental purposes were available from the same organisation. (8.3.1)

3.3.1.2 Exploring the possibility of joint activity with the Systems Develop­ ment Institute, Canberra, in relation to specific ADP development projects. (8.3.3)

3.3.1.3 Taking care in ensuring that any work undertaken during the interim phase leading up to equipment acquisition does not limit the equipment selec­ tion options which might otherwise be available. (8.4)

3.3.2 The Commission should acquire its own facilities, and accordingly should:

3.3.2.1 Commence, as soon as possible, longer term planning directed to­ wards acquisition of its own facilities. (8.5.1.1)

3.3.2.2 Facilitate 3.3.2.1 by proceeding to clearer specification and appro­ priate cost/benefit assessment of computer-based applications acceptable and

7

suitable to be developed and implemented in the Australian Capital Territory. ( 8.5 . 1. 1)

3.3.2.3 Prepare, after its computer requirements have been adequately iden­ tified, hardware- and software-oriented tender specifications, having due regard to the characteristics outlined in section 7.2.7. (8.5.1.1)

3.3.2.4 Adopt a policy of central control and co-ordination relating to all computer acquisitions and development and the computing standards to be adopted and maintained. (8.5.1.2)

3.3.3 The Commission should follow established acquisition procedures and accordingly:

3.3.3.1 The procedure of open tender for the acquisition of computing equip­ ment and ancillary facilities is recommended. (8.5.2)

3.3.3.2 The Commission should pursue a course of action designed to ensure that any equipment and facilities acquired are obtained under terms and con­ ditions no less favourable than those recently negotiated by the Australian

Government Stores and Tender Board for similar items. (8.5.3)

(These two recommendations are only relevant if it is not, in any event, mandatory for the Commission to observe these conditions.)

3.3.3.3 The Interdepartmental Committee on Automatic Data Processing should be kept informed of the Commission’s plans and strategies in the data processing field and the Committee’s advice should be sought as appropriate. (8.5.4.1)

3.3.3.4 The Commission should seek access, through the Interdepartmental Committee on ADP, to a range of equipment specifications and related docu­ mentation prepared within the Australian Public Service to provide a basis for the formulation of specifications appropriate to its own needs. (8.5.4.2)

(The previous two recommendations are only relevant if it is not, in any event, obligatory on the Commission to seek the support of the I.D.C.)

3.3.3.5 The Commission should adhere, if at all practicable, to the prin­ ciple that all equipment units comprising a single systems class be acquired from a single supplier. This approach should be reviewed by the Commission at some future time. (8.5.5)

3.3.3.6 In the selection of equipment appropriate to the needs of differing functional requirements under the Commission’s control, consideration should be given to the current and prospective needs for inter- and intra-systems communication and compatibility as appropriate. (8.5.6)

3.3.3.7 Subject to future review by the Commission, computing equipment maintenance should be provided by the suppliers of the equipment concerned at least for an initial period (8.5.8.1). Maintenance requirements should be included in any equipment specification issued by the Commission. (8.5.8.3)

3.3.3.8 The Commission should pursue a course of action designed to ensure that any maintenance services are provided under terms and conditions no

8

less favourable than those recently negotiated by the Australian Government Stores and Tender Board for similar services. (8.5.8.3)

3.3.3.9 In equipment specifications issued by the Commission, the essential characteristics of software regarded as mandatory should be identified. The suitability of software subsequently offered from the industry should be accorded weight in the equipment evaluation process. Specifications should

also seek responses in relation to any health care support software systems which are available. Suitable ‘user’ software of significance in this field should also be accorded weight in the equipment evaluation process. (8.5.9)

3.3.4 The Commission should evaluate available software (7.3) in this context:

3.3.4.1 It is not considered that there are viable and readily obtainable inte­ grated hospital and health care systems available at this stage and such systems should be regarded only as part of longer-term planning. (2.5, 7.3.7)

3.3.4.2 There appear to be a number of stand-alone computer sub-systems which could be adopted by the Commission in the shorter term. These include pay and personnel, stores and accounting, admissions and discharge and labora­

tory systems. The Commission should establish a program to evaluate these sub-systems within its determined priority framework, and implement where applicable. (7.3.7, 7.3.8)

3.3.4.3 Teleprocessing and data base handling software and facilities should be regarded as mandatory on major facilities contemplated for acquisition or longer term use by the commission. (7.3.3, 8.5.9.2)

3.3.4.4. Where practicable, the Commission should plan to collaborate with other developers of hospital computing systems in the Australian scene to develop, adapt and implement appropriate common software packages. (7.3.6)

3.3.4.5 In order to facilitate collaboration the Commission should seek repre­ sentation on the Computer Committee of the Hospital and Allied Services Advisory Council. Participation in Council activities is also regarded as poten­ tially advantageous. (4.7.9, 4.7.10)

3.3.4.6 The Commission cannot expect to rely on having its total require­ ments met from the available software and it is regarded as inevitable that it will need to engage in some pioneering work on hospital and health care com­

puting systems, especially relating to regional support and medical record linkage. Commission planning should provide for this requirement. In pioneer­ ing and, to a lesser extent, collaborative projects, the Commission should acknowledge the attendant risk factors associated with developmental activities.

It should not be anticipated, therefore, that all projects will meet with unequi­ vocal success and due allowance should be given to this aspect in planning. (7.3.6) 3.3.5 The Commission should establish appropriate computer accommodation and therefore:

3.3.5.1 Planning activities in the area of computer accommodation should be commenced at an early date. Environmental and security factors should receive particular attention. (8.6.2)

9

3.3.5.2 The Commission should consult with the Australian Department of Housing and Construction in planning and servicing activities in relation to computer accommodation and should seek through that department access to appropriate specifications of relevance. (8.6.2)

3.3.6 The Commission should establish an adequate computer staff to meet immediate and longer term computing requirements and therefore should:

3.3.6.1 Establish, as a matter of urgency, a senior computer administration within the commission comprising a second division position supported by two senior Third Division positions (7.5.1, 8.7.1.1). The chief computer services officer should be responsible for the provision of direct advice to the Com­ mission.

3.3.6.2 Obtain an adequate number of key ADP positions to support the senior staff identified in recommendation 3.3.6.1. (7.5.1, 8.7.1.1)

3.3.6.3 Give urgent consideration to the question of key personnel from the Commission visiting selected computing installations overseas which are oper­ ating in the health care delivery field. (8.7.1.3) 3.3.6.4 Explore all available avenues for early recruitment of experienced computing personnel including the possibility of overseas recruitment from the United Kingdom and North America. (8.7.1.1)

3.3.6.5 Give consideration to seeking further assistance from the Department of Health by requesting a continuation of the services of officers currently seconded in the department to ADP planning activities relating to the Com­ mission. (8.7.1.2)

3.3.6.6 Give consideration to requesting additional skilled support from the Australian Department of Health pending the establishment of its own com­ puter services group on an operational basis. The Commission could also request consultative advice on a mutually suitable basis from the Department of Repatriation. (8.7.1.2)

3.3.6.7 Give consideration to the relevance of employment of ADP consult­ ants on a ‘contract programmer’ basis in accord with the broad arrangements outlined in the Report. (8.7.2)

3.3.6.8 At a stage prior to acquisition of its facilities, seek the services of an experienced computer room manager. (8.7.3)

3.3.6.9 Recruit, as soon as practicable, trainee programmers for inclusion in the Australian Public Service Programmer-in-training Scheme or arrange for direct recruitment of such personnel from persons currently at an advanced stage in formal computing studies. An approach should be made at an early stage to selected departments requesting on-the-job training facilities for any trainee programmers selected. (8.7.4)

3.3.6.10 Establish an appropriate position and attempt to attract a suitable person as medical advisor. (7.5.1.1, 8.7.1.1)

3.3.6.11 Give consideration to the setting up of a multi-disciplinary Com­ puter Services Steering Committee, with advisory responsibility to the chair-

10

man for overall computing policy, developmental priorities and progress review. (8.7.6.1)

3.4 Recommendation·, the Commission should ensure that its staff are kept fully informed and involved with computing plans and developments through appropriate training and public relations arrangements:

3.4.1 A representative group from the Commission should visit selected hospitals and community health centres at which systems of interest to the Commission are in operation: such visits to be at an early date in order to allow planning and study to proceed. (10.2.1)

3.4.2 Projects should be developed only if both computer services and user sec­ tions are prepared to devote sufficient time and resources to provide adequate training for all staff involved in the project. (5.3.6, 10.3)

3.4.3 The Commission should recognise the role to be played by public relations so that early steps may be taken to commence appropriate activities. (10.4)

3.5 Recommendation: the Commission should take adequate steps to ensure that the provision of health care is not endangered by lack of systems reliability or alternative arrangements. (9.5.2)

11

CHAPTER 4—DEVELOPMENTS IN HEALTH CARE COMPUTING IN AUSTRALIA AND ABROAD

4.1 Introduction

4.1.1 It was recognised at any early stage that the work undertaken in this field by other governments and authorities would need to be considered in determining a practicable course of action appropriate to the Australian Capital Territory.

4.1.2 Committee was able to consider a wide range of literature relating to sys­ tems in overseas countries (see Bibliography). In addition, several members have had the opportunity to examine some such installations at first hand. One member,

early in 1973 had undertaken a 3 months World Health Organization Fellowship to study health-oriented ADP systems in the United Kingdom, United States of America and Sweden. On the basis of these observations and available literature, the Committee had considered that developments summarised below were relevant to its deliberations.

4.2 United States of America

4.2.1 Escalating costs in hospitals and the increasing complexities associated with patient charging structures, especially where government payments under Medicare or Medicaid are involved, have created a situation where economic justification of computer installations in the hospital environment is regarded as being generally proven. Accordingly, the computer is accepted as an essential piece of office equipment in the majority of hospitals. In addition, a great deal of research work is being undertaken at university hospitals on the basis of grants from Health, Education and Welfare. Research topics include physiological support systems, long term monitoring of discharged cardiac patients using tape recorders and ECG techniques to detect ‘sudden death’ indicators, nuclear medicine, laboratory systems, patient records, etc.

4.2.2 There is an amount of duplication of effort at the hospitals and universities as each authority strives to develop its particular preferred solution for a specific function. However, this unstructured effort has led to significant development, implementation and breakthrough, but at a price that may not have been necessary or desirable in a more structured approach.

4.2.3 Many people engaged in Medical Research in America have expressed interest in the ‘problem-oriented’ approach to patient care which is expounded by Dr Weed in Massachusetts. The initial concept of ‘problem-oriented’ health care did not require computer support. It is practicable to adopt a medical record format which is problem-oriented and to work from it. However, it became evident that significant improvement in real patient care in the larger environment of, say, a geographic region could not eventuate without automated information retrieval and service scheduling. It was subsequently recognised that the commitment to computing equipment and other resources necessary to sustain highly advanced systems over a whole community may need to be justified in terms of relevance to general medical development. In this regard, it has been noted that the Texas Institute of Rehabilitation and Research at Houston has adopted an intensive

12

approach to problem-oriented patient care in respect of its 87 patients. The hospi­ tal utilises more than 50% of the available capacity on a large IBM 360/50 installation at Baylor College, including a number of Visual Display Units and low speed terminals. The hospital staff believe that the power of an IBM 370/155 would be necessary to provide optimally for the very specialised care of the hospi­ tal’s patients, but could not be justified in respect of the small number of beds

involved.

4.2.4 The development and implementation of laboratory support systems are well advanced in the U.S.A. Historically, increasing pressure of laboratory work has led to automation with autoanalysers and Coulter Counters. However, this only shifted the bottleneck and the need to control, collect and monitor the data from these tests automatically became apparent. There were significant gains to

be had in both reduction and simplification of paper work and laboratory tech­ nicians’ throughput. Thus with chemical pathology and part of haematology provid­ ing a strong basis for cost justification, developments have spread in other areas of laboratory work, providing greater control and accuracy, reduced paper work

and increased productivity. In the light of high and increasing salary scales, the economics of this development can readily be demonstrated as a function of the size of the laboratories and the number of tests performed.

4.2.5 Aggregated statistical and control information is also available to partici­ pating hospitals through at least two organisations which process data from the hospitals by computer. The American Hospitals Association in Chicago provides comparative performance statistics on all hospital activities in groupings of similar

size and region. These statistics are administratively oriented and guide the hospital administrator on decision making regarding the efficiency of the hospital. The Commission on Professional and Hospital Activities, Ann Arbor, provides mem­ ber hospitals with the continuing results of a Professional Activity Study, aimed

at displaying the overall patterns of health care in the hospitals, e.g., level and standard of nursing care, dietetic support, etc. This is supplemented by a second major program known as the Medical Audit Program, which facilitates the evalua­ tion of the quality of medical care reflected in medical records. For example, the

net result from a sustained policy to achieve a reduced average length of stay in a particular hospital may show up as a higher incidence of deaths after discharge or re-admission for further treatment for the same complaint.

4.2.6 Growing concern with the rapidly increasing utilization of services available under the Medicare and Medicaid programs, the escalating unit costs of those services and the evident disparity in the level and quality of service between regions has led to the recent introduction of legislation relating to the establishment

of Professional Standards Review Organizations (P.S.R.O.s). These peer review bodies have been set up on a regional basis with broad responsibilities to lay down guidelines for procedures to be followed in various medical situations and to ensure that institutional services are both medically necessary and provided in

accordance with professional standards. To this end, P.S.R.O.s are empowered to impose sanctions. In carrying out their responsibilities P.S.R.O.s are required to review profiles of care and service delivered to Medicare and Medicaid benefici­

13

aries by both individual health care practitioners and institutions. Undoubtedly the establishment of inter- and intra-regional ‘norms’ of professional practice and their on-going review, together with continuing assessment of data relating to patients, practitioners and institutions will make even greater demands on computer support for the interchange and analysis of medical data.

4.3 England

4.3.1 The use of computers in hospitals in England has followed a different pattern from that evident in the United States. Much more control is exercised by the central authority, the Department of Health and Social Security, both in terms of equipment purchased and systems development.

4.3.2 Development and implementation of computers in hospitals has progressed in two main streams. On the one hand, administrative support for accounting, payroll, statistical reporting, is considered proven, necessary and is well advanced. This work is undertaken at the regional level in 14 regional centres throughout England and Wales. These regions are standardised on ICE 1904(s) computers and every effort is made to achieve uniformity of systems and processing.

4.3.3 On the other hand, all remaining aspects of hospital computer system development are at present confined to experimental systems in a small number of hospitals. In 1968, the Secretary of State agreed to launch experiments of this type in hospitals. Mainly, this provided support for forward thinking people in hospitals

who were already working in the area. In 1971 a complete review of the results which had been achieved to that time in developing hospital computer systems was undertaken by a group consisting of consultants and professional medical and computing people, who produced a comprehensive Report to the U.K. Minis­ ter for Health and Social Security on the subject, (known in the health circles as the ‘Red Book’).

4.3.4 Basically, as a result of that Report, there were seen to be three stages of progress in the development of hospital computer systems. Reaching the point of transfer from one stage to the next was now viewed as a more important criterion for funding than the amount of time the project had been located in a particular stage. The stages are:

(i) Experimental Stage—followed by evaluation for development.

(ii) Developmental Stage—followed by evaluation for general implementation.

(iii) General implementation in other hospitals.

4.3.5 It was recommended to and agreed by the U.K. Minister for Health and Social Security that the Department would pay the full cost for experimental work and half the cost of developmental work, but hospitals must budget for the imple­

mentation costs of proven systems.

4.3.6 The Department has implemented a system of regular and routine review of experimental and developmental projects. There are two co-ordinated and over­ lapping methods of review. Project officers continually oversight and look after projects (e.g. the Exeter project which is oriented towards the development of a

regional health care delivery system embracing hospital inpatient, outpatient, clinic

14

and private practice), while application officers continually review and liaise on applications (e.g. the development of a patient record at a number of separate projects).

4.4 Sweden

4.4.1 In Sweden the approach to automation in the hospital field has also been structured. Early considerations started with Chemical Laboratory Systems about 1962-63. During 1965-66 public interest increased in relation to the question of medical records and computing.

4.4.2 As a result of this interest, a concept was formalised to provide for each person a total integrated medical record. Much thought was given to the structure and development of such a record and its linkage through time and space. How­ ever, it is now recognised that the development of such a medical record system

is more a final goal rather than a present objective.

4.4.3 In 1967, as a result of consideration of the difficulties involved in providing such a total medical record system, there evolved a multi-satellite philosophy, based upon a network of computers linked by a telecommunications grid, and this

has led to the planned development to provide a generalised Multi-Satellite System. There was some criticism of this approach on the basis that it was far removed from a total integrated medical record system. However, it was accepted that the multi-satellite approach would lead to improvements in some areas, although

concern was expressed that the improvements may be restricted to particular areas or size of hospitals, rather than having general application.

4.4.4 Sweden is divided into 7 medical regions, each containing approximately 1-2 million people. Each region has a major Regional Hospital which can provide the full range of medical service and specialties. Each region is composed of a number of counties (approximately 5) and each county has a County Hospital of

about 1,000 beds which provides a good range of services, but not as comprehen­ sive a range as that provided in the Regional Hospital. At a lower level still, individual towns may have hospitals of up to 600 beds.

4.4.5 Consideration was given to one concept of applying ADP to this general scene by identifying the specific functions which were common to all levels of service and developing systems for these functions in such a way that they could be applied generally, with very little modification if any at all. However, this con­

cept was rejected in favour of a general approach aimed at covering the over­ lapped segments of all functions. In retrospect, there has been thought in some quarters that the modular function concept may have given better results in the

long run. This view is, however, not now generally held among health planners.

4.4.6 The development of the adopted system was built around a concept of a grid system supplying health care and supported by satellite computers, eventually, at all points of the grid. Thus there would be a central computer, regional hospital computers, local hospital computers and terminal service to the medical practi­

tioner. It was considered that there would be the capability of complete interchange of medical records through all states providing medical service, both by reference and request. But the central computer installation was to be only a Reference and

15

Indexing Centre, which could be used to identify patients and point to the various locations at which parts of their medical record were available.

4.4.7 What has been developed and put into practical routine daily work is sup­ port aimed at health service at the local hospital level. Some consideration has been given to the problems of developing the regional level of support, but it was soon recognised that the hospitals did not have the type and power of computer required for this stage. Some 3 years ago the Akademic Hospital at Uppsala obtained an IBM 370/155 and is now using data management techniques to store and manipulate the patient record. The hospital staff has also developed ancillary programs for both statistical extraction and medical record handling of a gener­ alised nature, but these have not yet been put into production.

4.4.8 It was considered necessary to establish a top level Review Committee to examine and report on the legal situation, especially with regard to the aspect of confidentiality, prior to the implementation of the medical record on computer at the regional level. Eventual implementation of the Central Register, which is being developed separately at a further Regional Centre, is also dependent upon the recommendations of the Review Committee. It is now understood that the Swedish Government has taken legislative action to secure the privacy and protection of its citizens against intrusion by computerised information. A Data Inspection

Board has been established to screen applications and grant or revoke permission to keep personal registers.

4.5 Other Countries

4.5.1 Apart from Israel, where it is understood that an Integrated Medical Record for the entire population (3 m.) is being developed on a University computer installation, there is little known in Australia about developments in this field in other countries of the world. Undoubtedly, there is work being undertaken in such countries as Canada, Denmark, Germany, Japan and Scotland but there was little literature to hand at the time of Committee deliberation. However, it is understood that most computer manufacturers view the hospital field as being an extensive market for computer hardware and peripherals over the next 15 years at least.

4.6. Summary of Overseas Developments

4.6.1 At least three overseas countries are at present making very substantial capital and other resource allocations in the development of hospital computer systems. In the United States of America this development is very unstructured, but individual hospitals, especially teaching hospitals, have made worthwhile indi­ vidual progress. The overall cost appears to be high and there is no apparent move towards standardisation across the country, although developmental activities in a relatively small number of multi-hospital complexes are now taking place. Sub­ stantial advancement has occurred in the hospital ‘business office’ environment and some administrative and statistical functions have been tackled on a broader front.

4.6.2 In England, the business and administrative functions have been split off into regional computer centres, which are standardised, and hospital system devel-

16

opment is proceeding in a co-ordinated and more structured manner than in the United States of America. Multiple development of an application across more than one project is monitored by the Department of Health and Social Security to

try to achieve some degree of standardisation and to lessen duplication of effort. Similarly, there is a tendency to standardise on a single range of equipment, pro­ vided that the standard can be shown to meet the hospitals’ requirements. In Sweden also regionalisation of facilities and structured development is the accepted

pattern.

4.6.3 A variety of installations and groups of persons expert in this field are emerging from the present developments in these three countries. However, the more structured and controlled environments in England and Sweden appear to have greater relevance to the longer-term aims of the Australian Government.

4.7 Developments in Australia

4.7.1 Australian Department of Health has not as yet undertaken any work in this field.

4.7.2 Australian Department of Repatriation The Repatriation Department has made substantial progress in the development and implementation of computer- based hospital support systems in Repatriation Hospitals. An on-line system for inpatient admissions and discharges is operational at R.G.H. Concord. The system is based on Visual Display Units and remote printers and maintains information relating to patient identity, location and condition. It provides on-line data inter­

change with other ADP systems, e.g. biochemistry, and serves a wide variety of functions ranging from bed availability to patient enquiries. An IBM 1080 Data Acquisition System is operational in the Biochemistry Department at RGH Con­ cord. Other systems include Inpatient Morbidity Statistics, Generalised Analysis

(Statistical), Drug Usage (Statistical) and Management Information.

4.7.3 New South Wales The Health Commission for New South Wales is currently engaged in a major feasibility study relating to the introduction of com­ puting to the various aspects of hospital administration in that State. In addition, a number of systems have been developed and implemented at various hospitals

throughout the State. These systems include On-Line Biochemistry, Radiotherapy, Bacteriology, Dietetics, Blood Transfusion, Obstetric Medical Records, Nurse Ros­ tering, Thyroid Disease Diagnosis, Payroll and Management Reporting, Hospital Monthly Reporting, Inpatient Billing, Outpatient Billing and Patient Index.

4.7.4 Victoria A Computer Studies Group has been established by the Hos­ pitals and Charities Commission, Victoria, for a number of years and this Group, working at the Monash University, has made good progress in the application of computers to various aspects of hospital commercial and medical administration.

Systems now in operation cover Personnel and Payroll, Creditors, Patient Account­ ing, Mailing and Membership, Personnel, Preventive Health Reporting, Patient Reporting, Clinical Biochemistry Autoanalyser Monitoring, Obstetric History Re­ porting, Biochemistry Quality Control Pooled Serum, and various other non­

hospital systems such as Domiciliary Nursing Service. An extensive program of future development in health care systems has been planned. As at March 1974

17

there was a total of 58 Victorian hospitals and 8 other allied services using one or more of the facilities and systems provided and developed by the Computer Studies Group. Additional hospitals are being introduced to these systems at a rapid rate. The Woden Valley Hospital in the A.C.T. is currently being serviced by this Group in respect of Personnel and Payroll processing, Assets Register/Preventive Main­ tenance and Creditors/General Ledger. Reference is made to these systems and their use in the A.C.T. context elsewhere in this report.

4.7.5 Queensland The Department of Health has an ADP Planning Group which has developed and implemented a number of systems in hospitals in Queens­ land. Implemented systems include Manufacturing Dispensary Hospitals Stock­ taking and Drug Catalogue Listing, Brisbane Public Hospitals Inpatient Recording and Reporting, Obstetrics Data Processing (adapted from N.S.W. System), Path­ ology, Hospital Payroll (Statistical) and various Radiotherapy systems developed by the Queensland Radium Institute.

4.7.6 South Australia In August 1971 the Hospitals Department of South Aus­ tralia proposed the development and implementation of a computer system for Flinders Medical Centre. It was also proposed that the model systems designed for the Flinders Medical Centre should be suitable for installation at other hospi­ tals on a State-wide basis. Systems which have been implemented include Payroll for all Government Hospitals and Allied Services in South Australia, Payment of

Creditors’ Accounts, Pollution Survey (Statistical), Patient Billing, Renal and Transplant Bacteriological Data (Statistical), Asthma Survey (Statistical), Blood Donor Call-Up and Admissions, Transfers and Separations.

4.7.7 Western Australia In 1972 the Medical Department issued specifications for the supply, installation and maintenance of a computing system for the Perth region on-line medical information system. The system is to be implemented in Perth’s five teaching hospitals to help satisfy their rapidly expanding information requirements. The five hospitals concerned are Royal Perth, Sir Charles Gairdner, Fremantle, Princess Margaret and King Edward Memorial for Women. As a result of this specification a contract has been let to CDC to supply a computer. Planning and development has proceeded with systems for Medical Administration, Patient Orders and Results, Payroll and Personnel, Nuclear Medicine, Public Health Laboratories and Pulmonary Physiology. Some of this work is oriented towards two small DEC computers.

4.7.8 Tasmania The Director-General of Health Services has implemented sys­ tems for payroll processing for 3 hospitals, based on programmable electronic accounting machines and commercially-developed systems.

4.7.9 H A S AC— Computer Committee In 1971 the Conference of Australian and State Government Health Ministers established the Hospital and Allied Ser­ vices Advisory Council. The Council comprises senior management of the Depart­ ments for which each Minister is responsible. The Department of Repatriation and Social Security have been invited to participate in Council activities. Five Standing Committees work to the Council in providing advice across the broad areas of activity in the Hospital and Allied Services field. The Committees are known as

18

the Computer Committee, the Uniform Costing Committee, the Research Commit­ tee, the Construction Planning Committee and the Post Graduate Accreditation Committee. The Computer Committee meets each six months and, apart from its advisory role to Council, one of its major objectives is to ensure the free inter­

change of information between member organisations in relation to the planning and development of computer systems in the health care field. Computer systems are exchanged between member organisations as a means of reducing the duplica­ tion of effort which would otherwise occur.

4.7.10 The HASAC Computer Committee has proved to be a valuable forum. The Commission should seek to participate in the activities of the Computer Com­ mittee and the Council.

19

CHAPTER 5—THE COMPUTING NEEDS OF THE CAPITAL TERRITORY HEALTH COMMISSION

5.1 Computing needs at commencement of Commission activities

5.1.1 The Committee’s first Term of Reference called for advice in relation to computing systems which could be regarded as essential to the activities of the Commission from the date of its formation. As the establishment of the Commis­ sion was imminent, the task was accorded priority by the Committee. Its findings and recommendations in the matter are contained in an Interim Report which was finalised in December 1973. The Report received the support of the A.C.T. Co­ ordination and Implementation Committee at its meeting of 13 December 1973 and was accorded Ministerial approval on 2 February 1974.

5.1.2 The Committee concluded in its Interim Report that Commission activities would, at the outset, necessitate operation of computing systems in the fields of Personnel/Payroll, Creditors/General Ledger, Assets Register and Preventive Maintenance. The Report recommends that these initial needs be met by access to selected computing systems developed and maintained by the Computer Study Group of the Victorian Hospitals and Charities Commission. Early installation of these systems across all relevant sectors of the Capital Territory Health Commis­ sion was proposed. The 1st July 1974 was suggested as a desirable date for com­ pletion of this introductory phase.

5.1.3 The Committee’s recommendation served to endorse prior arrangements concluded between the Canberra Hospital Management Board and the Victorian Hospitals and Charities Commission for access to certain ‘Monash’ systems by

Canberra and Woden Hospitals.

5.1.4 The Systems selected from the ‘Monash’ suite were closely examined by the Committee and were regarded as highly suitable at this time for Health Com­ mission purposes. However, for the several reasons detailed in the Interim Report, the Committee advised against long-term use of the Melbourne-based ‘Monash' systems. The Interim Report therefore recommended that the ‘Monash’ systems be converted as soon as possible for future use on a Canberra-based computing facility administered and operated by the Australian Government or one of its agencies.

5.2 Areas of potential need and future development

5.2.1 The Committee’s examination has shown that computers are being applied effectively throughout the world to a wide and increasing range of uses in health care, administration and planning. In many cases the introduction of computing

has enhanced functional capability or capacity, whilst in others, tasks are being per­ formed which are beyond the capacity of alternative procedures. This development does not lessen the need for a well planned and professional approach to the intro­ duction of computing techniques into the general field of health care delivery. It establishes in the Committee’s view however, a prima facie case that computing facilities can be introduced into the activities of the Commission with considerable benefits to administration and public alike.

20

5.2.2 To provide a broad basis for consideration, the Committee has attempted to cover a fairly exhaustive spectrum of possible computing applications within the range of activities proposed for the Capital Territory Health Commission. The several areas of potential need are covered in some detail at Appendix 7. Although

these areas have been identified and isolated on a functional basis there are many points of commonality and inter-relationships which should be given close con­ sideration in planning towards a fully integrated system.

5.3 Criteria influencing the allocation of priorities

5.3.1 Term of Reference 5 calls for the recommendation of priorities for study, development and implementation of the various phases of relevant computer sys­ tems. Committee was not prepared to recommend priorities for development and implementation. It was of the opinion that any such recommendations should

properly be made only after a close and intensive pre-analysis and feasibility study of the application areas that have been identified. Since such studies were clearly beyond the scope of the resources available to Committee, emphasis has been placed on identifying those projects which seem particularly suitable for early study and assigning priorities accordingly. This is not to say that applications which are accorded high priority for study might not also continue through to early implementation—indeed, one would naturally expect such a progression—·

but certain factors which might normally influence such a decision (e.g. Commis­ sion policy, availability of developmental funds and resources, user enthusiasm, etc.) cannot be adequately appraised at this time.

5.3.2 It would seem appropriate to outline a number of factors which merit consideration in any assessment of application suitability and in any attempt to assign relative priorities. The criteria referred to below have, whenever practicable, been taken into account in arriving at recommendations but, as may be seen, a

comprehensive assessment has not been possible at this stage.

5.3.3 (a) Cost benefit analysis Whilst it is generally agreed that there are many areas of hospital and health care system development that do not lend themselves easily to such analysis, primarily because of the intangible and non- quantifiable (in dollar terms) nature of many of the anticipated benefits, it would still seem appropriate to attempt such an analysis. Certainly developmental and

running costs should be estimated and should provide a budgetary framework within which progress may be appraised. Such costs might include:

Capital equipment In cases where the project could be accommodated by existing hardware the costs might be derived on a marginal basis.

Developmental resources (human) The costs of programming staff and subject matter liaison personnel will normally represent a sizeable proportion of the total budget but may be offset to some extent where appropriate software or systems packages are available from other sources.

Ongoing costs This would include such items as operations and maintenance staff, line charges, data preparation, machine time, etc.

Consumables.

21

5.3.4 In addition the objectives of the system should be defined, if only to pro­ vide a yardstick by which the ultimate success of the system might be measured. This will also provide a basis to identify those benefits which are anticipated to

arise from the system and for attaching dollar values wherever possible and appropriate. Such benefits might be viewed as falling into the following four categories:

(i) Benefits to the institution:

improved resource utilisation, e.g. reduction in clerical staff; improved productivity, e.g. a greater throughput of tests within the clinical pathology laboratory; reduction in the average length of stay in hospital; reduction in the average cost per bed day; increased bed utilisation; improved management and control information.

(ii) Benefits to the patient: reduction in the length of stay; reduction in waiting times for outpatients; improved medical care; improved services.

(iii) Benefits to staff:

improved communications and better working relationships; faster and easier access to records; a reduction in the clerical component of the activities of professional staff.

(iv) Benefits to society:

better utilisation of medical and para-medical resources; improved facilities for clinical and epidemiological research; a generally improved level of health care arising from enhanced service facilities and advancement of knowledge in regard to the detection and treatment of illnesses.

5.3.5 Whilst most of the factors referred to under (i) are measurable in dollar terms, those under (ii), (iii) and (iv) are perhaps less quantifiable. They should nonetheless be identified and subjected to critical appraisal.

5.3.6 (b) Availability of resources The practicability of undertaking a par­ ticular project will be greatly influenced by its developmental manpower resource requirements and by the availability of these resources during the proposed devel­ opmental phase. Questions of redeploying existing resources and/or acquiring additional staff on a permanent or temporary basis will need to be examined according to the significance of the project. It is perhaps important to stress that the resources referred to here are not confined to computer staff and that the Commission should seek always to ensure that there is an adequate availability of senior staff from the subject matter area to assist in project development, per­ haps even to the extent of seconding staff (at least on a part-time basis) to the project team.

22

5.3.7 (c) Implementation timetable Those applications which appear likely to result in early implementation might also offer additional benefits from the standpoint of motivation. Particularly during the infancy of computing support within the Commission, the prospect of being able to provide tangible evidence of

success at an early stage might help to convince any sceptics and reinforce the enthusiasm of adherents.

5.3.8 (d) Probability of success Some of the projects to be undertaken may well be experimental or, at best, ‘pioneering’ in nature and may consequently carry a certain failure risk factor. This risk will obviously need to be taken into consideration before approval is granted to embark on a developmental program.

5.3.9 (e) Relationship to existing systems Projects which have a close rela­ tionship with existing systems or with systems already in a developmental stage may be given a more favourable arbitration on the basis of expertise that has already been developed in the area. However, there appears to be a danger here that excessive application of this argument could lead to a situation where develop­ mental activity becomes constrained within narrow boundaries and where other,

perhaps more beneficial, applications are by-passed.

5.3.10 (f) Availability of existing software The availability of existing appli­ cations software support packages may have an important influence on the decision to proceed with a project. They must of course receive close scrutiny in the light of their suitability within the proposed operational environment, cost justification, ease and timeliness of implementation and savings in developmental resources.

5.3.11 (g) Furtherance of Commission policies Projects which have a direct bearing upon predetermined policies would naturally have a higher likelihood of acceptance than others. For example a decision to centralise food service facilities might well give impetus to a proposal to develop a foods inventory, purchasing/ menu planning system.

5.3.12 (h) Projects of national significance Due regard must be paid to expressed government policy when assessing projects aimed at supporting national information flows (e.g. medical record linkage) and standardising on formats and procedures. Whilst any such project might still be subjected to critical review in terms of developmental costs, a decision to proceed could well be influenced by such factors as moves towards inter-State co-operation, nationally determined

information requirements or a policy of leading the way in the A.C.T.

5.4 Definition of priorities

5.4.1 The Committee has considered each of the possible areas of application and has assessed each application’s viability and priority on the basis of:

(i) the magnitude of benefits which might be anticipated following successful introduction of the system;

(ii) the scale of developmental manpower resources which might be required to implement and the consequent likely time scale for implementation; (iii) the probability of successful implementation:

23

(iv) the availability of existing application and software support packages; (v) the potential availability of computing resources.

5.4.2 No attempt has been made to rank individual applications in relation to each other but rather it was decided that three broad priority bands should be established and that applications be assigned to one of these categories. In some instances certain components of a particular application may be assigned a higher

priority than others.

5.4.3 The priority classifications which have been employed are defined as follows:

Priority I (a) Those applications where prima facie evidence exists indicating a high benefit payoff, where successful implementation may be anticipated with a degree of confidence, where user reaction appears enthusiastic and

where, in most cases, software packages are readily available.

(b) Applications which, whilst perhaps not as profitable as those listed under Priority 1(a), could be implemented relatively quickly with minor resource dedication and could therefore provide a valuable impetus to computing activity within the Commission.

Priority II Those applications which, whilst meriting further study present less evidence of potential benefit, urgency, economy of implementation or general feasibility.

Priority III Applications which, in the short term, offer little material evidence of potential success in terms of anticipated benefits or those which might make an exces­ sively high demand on resources. Other factors such as a need for policy clarification, the experimental nature of the project, lack of readily available software and user indifference have also been considered in assigning this priority.

5.5. Assignment of priorities 5.5.1 The following list sets out the applications or components thereof assigned to each of the defined priority categories. As mentioned earlier no attempt has

been made to rank applications within each category and their ordering is there­ fore not significant.

5.5.2 The table attached at Appendix 8 outlines and comments on many of the criteria which have influenced the Committee’s findings.

Priority 1(a) (a) Commercial Systems:

Personnel/payroll General ledger/accounts payable Assets register/preventive maintenance

Inventory control Budgetary control

24

(b) Clinical Pathology:

Equipment automation Automated test ordering procedures, schedules, worklists, etc. Maintenance of cumulative patient records and preparation of test result reports

Preparation of management information reports oversighting laboratory activity

(c) Clinical Service Departments:

Applications related to the preparation, control and analysis of gamma camera examinations Maintenance of patient diagnostic data (Radiology and Nuclear Medicine) Patient recall systems (several departments)

(d) Health Care Activity Analysis:

Production of statistical reports and indices relating to institutional, re­ gional and community health care delivery Ad hoc production of special purpose reports as requirements arise

(e) Inpatient Management:

Patient identification/record retrieval Bed allocation and release Patient location and condition reports Predictive discharge reports

Bed/ward census Nursing dependency estimates Discharge notices Ad hoc enquiry facilities

(f) Medical Records:

Patient identification Automation of basic medical record formats; active and archival Staff records Medical Audit

Morbidity statistics Enquiry facilities for research and epidemiological studies Record linkage

(g) Preadmissions:

Compilation and maintenance of waiting lists Operating theatre schedules and bookings Bed bookings Patient appointment advice

Advice to service departments Creation of nucleus patient record Nursing dependency estimates

(h) Health Centres District Nursing

25

Mental Health Services Child Health Nursing Homes, etc.:

Establishment of basic medical record systems Record linkage

Priority 1(b)

(a) Nurse Scheduling:

Scheduling of student nurse training programs

(b) Operational Research/O. & M.:

Generalised statistical packages Critical path analysis Simulation techniques Optimisation techniques

(c) Physiological Monitoring/Measurement:

Arterial blood gas analysis Pulmonary functions analysis Fluid and electrolyte balance, etc.

(d) Preventive Health:

Patient recall systems Monitoring of staff working under health hazard conditions

(e) Registration Boards:

Maintenance of medical and paramedical registers Production of mailing lists

(f) Blood Bank:

Maintenance of donor file and provision of recall facilities

Priority II

(a) Analysis of ECG recordings

(b) Clinical Pathology:

Integration with central medical records system

(c) Clinical Service Departments:

Automated test ordering, scheduling and reporting Patient records (other than Radiology and Nuclear Medicine)

(d) General Communications:

Inter-institution Intra-institution

(e) Intensive Care Monitoring

(f) Nurse Rostering:

Rostering system based on nursing dependency estimates Integration with personnel system

26

(g) Patient Scheduling:

Inpatients Outpatients

(h) Pharmacy Systems:

Pharmacy administration/stock control Medication ordering and dispensing Patient medication profiles Recording of adverse drug reaction data

General drug control Drug recall Evaluation of clinical trials

(i) Preventive Health:

Evaluation of various screening schemes

(j) Ad hoc Research Projects

Priority III

(a) Automated History Taking

(b) Computer-Aided Diagnosis

(c) Food Services

(d) Medical Records:

Maintenance of problem-oriented records

(e) Nursing Orders

(f) Patient Billing

(g) Drug Information

(h) Supply Division

(i) Surgery

(j) Library Services

(k) Office Services

(l) Ambulance Service

(m) Private Health Facilities

5.5.3 The Committee wishes to emphasise that the conclusions it has drawn with regard to application priorities have in some cases been based on value judgments with which there may be some differences of opinion. It has not been possible with

the resources and information available to devote to the task a measure of effort approaching that which would be required for a comprehensive study. Nor would such a study appear warranted at this stage when the objective has been to com­ pile a report which would assist in gauging the staffing and facility requirements

of the Commission and which might, at some later date, provide broad guidelines for Commission staff in determining their own needs and priorities in response to existing pressures and initiatives.

27

CHAPTER 6—COMPUTER-BASED MEDICAL RECORDS

6.1 General Considerations 6.1.1 Arising from consideration of the computing needs of the Capital Territory Health Commission, it became evident to Committee that computer-based medical

records will play an important part in future planning, and the integration of health services within regions will necessitate a solid basis for linkage of those records. However, the contentious nature of this subject, together with technically challenging problems, make full computer linkage a long-term goal rather than an immediate objective. The Committee regards this goal as being attainable in stages and an essential background for developmental and planning activities. Notwith­ standing its importance, however, it is by no means the sole criterion for decision on the computing needs of the Commission.

6.1.2 The accelerating demand for medical care and the increasing level of sophistication of the care provided is placing greater and greater emphasis upon the need to collect, organise and retrieve information related to health care deliv­ ery. The focal point of this information is of course the assembly of data relating to the individual patient’s medical history which, taken in isolation, augments the physician/patient relationship and which in its larger corpus serves as the data base for epidemiological studies, management and clinical research, medical edu­ cation, the determination of resource needs, monitoring of on-going health pro­ grams and planning in the light of trends in community morbidity. There seems little doubt that the rapidly-increasing information demand together with the attendant pressures on medical and paramedical personnel to collect, record and collate the information will not be reversed and that an increasing dependence on information technology to serve these objectives will become apparent. Although the scarce medical resource should not be further eroded by denying it full oppor­ tunity and support in the practice of its profession, this technology must be care­ fully controlled. The role of the computer must not be one that intrudes on or disrupts the traditional physician-patient relationship but rather one which sup­ ports and enhances it. To this end the positive endorsement and active involvement of the profession should be achieved and maintained both prior to and throughout the move towards computer-based medical records.

6.1.3 There are three broad areas in which computers are being used throughout the world in relation to medical records. Firstly, they may function as data col­ lectors acquiring and assembling the many different types of information relating to the patient. Some examples of the use of computers in this area include:

automatic taking of patient histories by administering questionnaires and analysing the replies;

the inclusion in computer-held files of medical histories for hospital inpatients including data relating to diagnosis, therapy and prognosis;

the capture of patient-related data within the ‘laboratory’ environment either through direct interface with equipment or via a human intermediary (this would encompass such areas as the pathology laboratory, radiology, nuclear medicine, etc.);

28

the acquisition of synoptic patient-oriented information relating to medical en­ counters in a wide range of clinical environments including hospital outpatient clinics, health centres, pharmaceutical prescribing, psychiatric counselling, etc.

6.1.4 In its role as a data collector the computer provides a valuable means of relieving the physician of the tedium of compiling records and permitting him to concentrate his activities on the more pertinent task of actually delivering medical care. In addition it greatly expands the scope of information which may be col­

lected and the speed and accuracy with which the process may be accomplished.

6.1.5 Secondly the computer is able to store, organise and correlate vast amounts of data at a level of efficiency far exceeding any manual system and to impose rigid safeguards against loss, corruption and unauthorised access. The computer also provides flexibility in restructuring data to keep pace with changing require­

ments such as the creation of problem-oriented records or the establishment of a new nomenclature.

6.1.6 Thirdly the computer provides the only practicable means whereby this data may be retrieved in the large variety of structures and formats which are required. This has particular relevance where health care delivery is decentralised as it allows the varying requirements of different nodes to be precisely satisfied.

These requirements include the ability to select from a data base subject to ade­ quate security controls all the information relating to any one individual, and to make a timely and relevant presentation of facts which might assist in treatment. The requirements extend to comprehensive analyses of the entire data base in

order to derive statistics relating to morbidity, utilisation of services, epidemiologi­ cal investigations, evaluation of patient care, etc. In this third area the computer provides the potential for distributing relevant information on a scale which could not be contemplated by manual procedures.

6.1.7 The potential rewards to be gained from establishing a computer-based medical records system appear therefore to be extremely high; the investment of technological skills and developmental resources which is implied by such a course would seem to be equally imposing. While much has been achieved at the institu­

tional level in this area, more still remains in the developmental stage and the great and growing range and variety of clinical information available for collection presents an impressive challenge. Perhaps foremost among these problems is the need to codify data. Without such a system of classification, information may only

be committed to computer storage with a view to retrieving it in its original form and the ability to organise and collate this data is forfeited.

6.1.8 The establishment of computer-based medical record systems should there­ fore be approached with a degree of caution and confined to areas where recog­ nised systems of classification have been developed and feasibility proven.

6.2 Patient identification and record linkage

6.2.1 The problems surrounding patient identification are many and varied and have for some years now received the attention of expert bodies throughout the world. In fact, the subject has three distinct aspects:

29

(a) the need to unequivocally identify the patient during a course of treat­ ment in order to avoid the administration of therapy planned for someone else; (b) the need to identify all specimens and relate them to the individuals from

whom they originated;

(c) the need to correctly identify all items of data relating to the patient.

6.2.2 It is the last of these which poses the greatest problem with regard to development of computer-based medical records. The first two, of course, are covered by separate systems of supervision and control. The third problem may again be viewed as being subsumed by three separate levels of complexity.

(i) There is a paramount need to identify and bring together during a single episode all the various components of information relating to that course of treatment.

(ii) Within each node of the health care network there is need to identify and relate, through time, all data relating to the individual. This problem is manifest in all areas of health care delivery from the major institution such as the hospital through to the G.P.’s surgery. In passing, it is worth­ while mentioning that not only is it necessary to relate the information to the patient but, for medical and medico-legal reasons, it is frequently important that the doctor, nurse or paramedical who contributes the information is equally well identified.

(iii) Record linkage, that is, the ability to relate different items of information about the same individual recorded at different times and locations, demands a more universal approach to the identification problem.

6.2.3 The first two of these problem areas have been effectively satisfied by using a variety of identification methods ranging from the patient’s name and address in the G.P.’s surgery to the issuing of unit record numbers in the larger institutions such as hospitals. However it is the very fact that these areas have long been recognised and have been attacked independently that has compounded the overall problem, as the various systems which establish complete uniqueness within each organisation hinder the linkage of records.

6.2.4 Personal identification systems may be broadly classified in two groups. Firstly, those which rely on the allocation to each individual in the community of an arbitrary indentification number and, secondly, those which employ items of the individual’s personal information (e.g. name, date of birth, etc.) from which to derive and construct a key. The Committee gave considerable thought to the nature of the personal identification system which might optimally service the Canberra population and which would constitute a sound and acceptable basis for development or integration into a national system of linked medical records. In so doing it paid particular attention to the findings of the Hospital and Allied Services Advisory Council (see Bibliography) and endorsed the arguments put forward by that body in selecting the approach based on details of personal infor­ mation. It is furthermore recommended that a uniform method of facilitating medical record linkage be adopted within the A.C.T. health care network and

30

that the fifteen character key advocated by HASAC be used for this purpose. This key consists of:

(i) the first four characters of the surname, (ii) the first two characters of the first forename, (iii) the first character of the second forename, (iv) sex,

(v) day, month and year (excluding century) of birth, (vi) single digit tie-breaker.

6.2.5 The ‘tie-breaker’ provides a capacity within the system (manual or com­ puterised) to differentiate between two individuals who would otherwise have coincident keys and also preserves compatibility with any national systems which might evolve on the basis of the HASAC recommendations.

6.2.6 While no system of identification based on personal identification criteria can, with absolute certainty, uniquely identify each member of a population, the scheme that is advocated above provides a high level of discrimination. An analysis of the A.C.T. Electoral Roll comprising 90,818 entries was undertaken (see Appen­

dix 6) and the HASAC key derived and applied to each individual. Only one positive duplication was detected. Such a high level of discrimination underlines the suitability of the HASAC derived key as a vehicle for linkage of medical records in the A.C.T. The use of this key does not preclude the concurrent use of alternative patient identification schemes within the various nodes.

6.2.7 Throughout its deliberations Committee paid due regard to the Govern­ ment’s Party Platform as approved at the 29th Commonwealth Conference at Launceston in 1971 (Section XI; Health, para. 15) which seeks ‘the establishment of a health computer service on a national basis in which the details of an indi­ vidual’s medical record may be recorded, with the person’s consent, for the pur­

pose of research, statistics and the individual’s medical treatment’. It is generally acknowledged that clinical research and epidemiological studies would benefit immensely from the greatly expanded base of information afforded by a system of

computer-based record linkage. In terms of individual patient care the computer provides the potential for assembling what might otherwise be diverse and isolated pockets of information and rapidly presenting to the physician those excerpts which are relevant to the diagnosis and therapy of the present condition. Not only could such information materially assist in the clinical decision-making process but it might also serve to reduce the incidence of replication of expensive and

resource consuming diagnostic tests and examinations.

6.2.8 During the process of its work the Committee gave particular consideration to the strategic rationale by which a system of linked medical records could be effectively and efficiently introduced in the A.C.T., and with ways of retaining

confidentiality in a practical manner in an environment of voluntary participation. The results of these studies were embodied in a working paper entitled ‘Medical Record Linkage—An Evolutionary Approach’ (Appendix 5). The far reaching

implications of the proposals outlined in this paper, in terms of prospective bene­ fits to the community and the individual, involvement of the medical profession and acceptance by both the community and the profession led the Committee to

31

seek further reaction and advice. Accordingly the paper was distributed, in con­ fidence, to selected medical and lay personnel within the compass of the proposed Health Commission. The responses received were, on the whole, favourable and indicated a high level of enthusiasm with the approach outlined. In particular the Chairman of the Medical Advisory Committee replied, inter alia, ‘The Medical Advisory Committee supports the introduction of computers into medical record storage and appreciates the problems associated with such introduction’.

6.3 The privacy issue

6.3.1 Not least in the Committee’s deliberations were the many and vexing prob­ lems surrounding issues of confidentiality of information and general community acceptance of computer-based record linkage systems. Clearly the success of any scheme of linkage based on voluntary participation by the individual depends

substantially upon the level of coverage of the population and it is therefore essential that the mechanism for participation be simple and that any public fears and suspicions be allayed. The public has certain obligations which must also receive consideration, for example, the laws relating to notifiable diseases. Experi­ ence over many years has clearly indicated individual or community intolerance and cynicism to any errors or inefficiencies with computer systems, notwithstanding the higher error rates or inefficiencies which may have been patently obvious in

the manual systems which they replaced. Whilst these prejudices against computer systems which impact on the individual do exist amongst segments of the popula­ tion, it is equally clear that the concern and apprehension being voiced by learned authorities throughout the world at the proliferation of personal data banks is well founded. The existence of computer-based personal record systems does not in itself constitute the main threat to individual privacy; it is rather the advancing communications technology which, in the absence of effective legislative protection allows these files to be inter-related and accessed in an irresponsible manner. The Committee acknowledges the difficulties flowing from the privacy issue and noted the dearth of suitable legislation or appropriate standard practice in health care and its delivery. It was recognised by Committee that many of the rights, obliga­ tions and remedies which might be appropriate in the health care field would differ from those which had specific application to such areas as law enforcement, credit, financing, health insurance and banking.

6.3.2 The general question of privacy and data banks in Australia was considered by Professor Morison of the University of Sydney who was commissioned for this purpose by the Standing Committee of Attorneys-General. Professor Morison’s report to the N.S.W. Government was ordered to be printed on 5 April 1973 (see Bibliography). At the initiative of the Hospital and Allied Services Council, Professor Morison was requested to consider health-related aspects of the question and accordingly his report deals with certain of the several issues which arise in

that area.

6.3.3 The latent benefits to the community in an efficient system of medical record linkage can only be attained by establishing an environment where the following conditions hold:

32

(a) The public is adequately safeguarded by legislation against improper and illegal access to and use of personal medical data. Such legislation should also protect the custodian of the data to the extent of laying down clear guidelines concerning the establishment, maintenance and accession of

medical data bases.

(b) The design and implementation of computer systems handling personal and clinical information is carried out with full regard to aspects of con­ fidentiality and embodies adequate safeguards against loss, corruption or unauthorised access to patient-related data.

(c) The unequivocal acceptance and enthusiastic support by the medical pro­ fession of the concept of computer-based record linkage is manifest.

(d) The participating community is fully informed with respect to the poten­ tial benefits of such a scheme and of the broad means of achieving these objectives and safeguarding individual privacy.

6.3.4 Wherever practicable, positive steps should be taken at an early stage to foster these criteria. In the interim period it is important that progress towards record linkage and computer held records be constrained within prevailing public standards, subject to informed public inspection and comment, and consistent with

the requirements of a high quality of individual health care and medical treatment.

33

CHAPTER 7—RESOURCE REQUIREMENTS

7.1 Introduction

7.1.1 Having identified several areas of need in functions which would become the responsibility of the Capital Territory Health Commission, the Committee directed its attention towards the resources necessary to enable development and implementation of the applications which are involved. As it is not practicable to develop a number of major applications in parallel, the priority structure estab­ lished in Chapter 5 was taken into account. However, the scope of systems envis­ aged and the long utility life of computing equipment, led the Committee to consider central facilities which would be appropriate, with perhaps staged up­ gradings, to the longer-term requirements of the Commission.

7.2 Computer hardware

7.2.1 The Interim Report prepared by this Committee recommended that con­ version of selected administrative systems, developed by the Monash Computer Study Group, should be undertaken as soon as practicable to enable operation on a Canberra-based computing facility administered and operated by the Australian Government or one of its agencies. The minimum hardware characteristics neces­ sary for this purpose are listed in Appendix 9.

7.2.2 With regard to potential applications, it is apparent from Chapter 5 that there are many areas in which computer servicing may be developed in the health care field. It would seem at this time, such computer servicing is unlikely to be provided in toto for the whole health field from the one computer installation, nor is it considered desirable to develop in this direction because of the very sig­

nificant capital outlay required in the initial stages and problems with total depen­ dency on a single system. The scope of activity covering all aspects of health care delivery, patient care, administration and hospital communications facilities on the one hand and clinic-type work and/or, mechanical monitoring, e.g. driving gamma cameras, on the other, indicate that multiple pressures for development will tend to emerge. Co-ordination of requirements will be essential to ensure that the separate needs are met by central facilities or separate facilities as appropriate.

7.2.3 However, regardless of the type of facility sought, and whether or not it is logically or physically linked from node to node, the commitment in both capital and skills resources required to develop a total computer-based health care service will be so significant that it would appear prudent to stage development possibly on the basis of measured success in the initial areas.

7.2.4 Priorities for study have been recommended in Chapter 5. The priorities which are adopted by the Commission will establish the initial level of facility requirement and the appropriate phasing of tasks. However, because the initial requirement will be broad in nature and because computer acquisition must be

undertaken in the light of developing workloads during the probable equipment utility life, it has been practicable to make a broad assumption that the primary levels for development will include administration and patient management at the hospital or hospital group level, extending in the longer term to cover other areas.

34

Whether by computer links, or stand-alone decentralised units, the next develop­ ment step could include service and support sections, health care centres and clinics. Pathology laboratory computer systems may require development in con­

junction with or overlapping the primary levels for development. In other cases, the operational functions of institutions, centres, clinics, etc., would be serviced more adequately by stand-alone mini-computer facilities, although further benefits might accrue subsequently by linking them directly or indirectly to larger facilities. The Committee was of the view that integration and co-ordination of health care

servicing should proceed without impeding the basic on-going functional responsi­ bilities and activities of such out-rider health care delivery units.

7.2.5 This is not to deny the necessity in the initial stages, for some form of record linking within a hospital or in relation to a series of health care delivery nodes throughout a course of treatment, as is the case with manual-based systems

at present. At the outset this linking could be at a basic or rudimentary level. In the longer term however, it is considered that a need will develop for computer interfaces to be established between all automated facilities. On a broader front, it can be anticipated that there will be a need for linkage with other systems,

whether State or Australian Government controlled. This would be essential to the development of a nation-wide computer based linked medical record system. As the lead in development for such systems will come from the Australian Govern­

ment, it will be critical for the Commission to develop standards which would facilitate interfacing with previously developed computer data bases. The Com­ mission will need to apply strong central control both to achieve standardisation

within its own areas of responsibility and to facilitate interfacing on the national level.

7.2.6 With due regard for the phasing of development and implementation which has been referred to above, it is apparent that a potentially powerful initial facility should be sought for the Capital Territory Health Commission. Not only should these facilities meet priority requirements, but they should also support longer term development in administration, patient and resource management functions of the health care system, and in medical record linkage activities on a broad front. Accordingly, it is considered that the characteristics of the initial computer system to be sought should be as follows:

Adequate expansion capability to support the longer term administrative re­ quirements of the Capital Territory Health Commission. Recommendations have already been made about the immediate requirements of the Commission and subsequent steps to ensure against disruption to interstate processing. In

the longer term such systems as Payroll, Ledger, Stores, Statistics and others acquired or developed would run on the Commission’s facilities.

Capable of sustaining numbers and variety of ‘local’ and ‘remote’ terminals or of interfacing with a front end data communications computer or terminal which can perform this function.

Have adequate real or disc/drum simulated memory to service a number of batch and on-line applications simultaneously.

35

Be sufficiently powerful to handle such simultaneous batch and/or on-line applications, particularly in the light of anticipated continual random access to message and data files. It should be noted that general patient care and emergency treatments require that hospitals function 24 hours per day. Even though the level of activity may be low outside normal hours, this may require that some on-line systems be available constantly.

Provide adequate random access storage devices as may be necessary to pro­ vide the various data and message files required by the system.

Have a stable and proven operating system with appropriate tele-communica­ tion software and data base handler included.

Provide adequate hard copy output facilities to meet hospitals operations requirements and development needs in the initial stages.

Provide magnetic tape input/output for longer term archival-type back-up and serial file management.

Provide appropriate systems fall back and back-up to circumvent the possi­ bility of long term interruptions to hospital systems.

Provide for special departments such as pathology laboratory, ECG, Nuclear medicine, although these may be handled by stand-alone mini-computer sys­ tems.

7.3 Computer software

7.3.1 The utilisation of computer programs developed and tested by other users as a means of saving the time and resources required to develop the same or similar programs ‘in house’ has been examined by the Committee. These pro­ grams may relate to the method of operation of the machine in a functional

manner, or may be specific to particular hospital or health care requirements, such as Admissions and Discharge or laboratory systems. Such programs, ob­ tained from another vendor are generally termed software packages or ‘program packages’ and the term package has been used subsequently in this report to embrace such programs.

7.3.2 However, it is evident that the existence of a program package that is suitable for one particular environment does not necessarily imply that the same package will suit in an alternative environment. The main consideration is that the package under consideration must meet the broad functional and information requirements of the intending user.

7.3.3 There are three major categories of package which have been examined. These are Hospital Application, Data Base Handling and Teleprocessing systems:

Hospital Application: There appear to be three major sub-categories of data processing in this sphere and a range of other miscellaneous requirements. The major areas include Hospital Administration; Services and Facilities Schedul­ ing and Patient Management. Computer processing has been applied to just

about every aspect of hospital work at some level. The majority of developers

36

are anxious to sell or give their system to other users for a variety of reasons, including machine orientation, profit or cost recoupment, prestige, broadening the support and development base and potential backup. It should be noted that the acquisition of particular application packages may determine the

characteristics of supporting software packages in the teleprocessing and data base handling areas.

Data Base Handling: Computer manufacturers are producing for most large computers generalised routines for editing and structuring data into a standard retention format. The data is then available to meet any requirement for infor­ mation from the system. The data retrieved from the system can be further

processed by special ‘in-house’ routines or can be displayed upon visual dis­ play units or other terminals. Typically, the Data Base Handler updates or creates all levels of the one record at the one pass and allows easy reformatting of existing records, to save programmer time and eliminate errors. Generalised

data base handlers are most useful in a situation where only a percentage of the data base is being updated at the one time and/or where random access to the whole or various parts of individual records is required on a routine and

continuing basis, particularly with multiple users of the one record. Hospital processing appears to have the characteristics which suit data base processing and a number of apparently successful systems are known to have been implemented using data base techniques.

Teleprocessing·. Experience indicates that hospital systems are typically required to service a variety of on-line peripheral units, many on a remote basis, through a teleprocessor hardware device. In most cases, specialised teleprocessing pro­ grams are required in the computer to drive the teleprocessor hardware, that is, to present to it properly structured messages for transmission to the par­ ticular peripheral unit and to receive back and process messages which have been transmitted from the peripheral unit. In many cases a package of this nature is already included as part of the data base handling software, which has been described above. It is anticipated that the types of teleprocessor

package available from computer manufacturers or from specialist software houses would be adequate for the general communications task of hospital processing. Accordingly, it is considered that hospital development should be

based on standard available software of this nature. However, cases are known and have been observed where, in the absence of suitable alternatives, special­ ised in-house teleprocessing packages have had to be written in certain hospitals where the characteristics of processing required a very high level of interactive transmission over a number of terminals.

7.3.4 Many computer program packages seen in situ in the working environ­ ment in which they were developed appear attractive to the observer. Typically, the observer is working at an earlier stage of development, and cannot yet detect any shortcomings or flaws in the system while the developer is reluctant to dwell

on anything but the better aspects of his system. Accordingly, it is appropriate in evaluation of such packages to establish a check list covering the criteria which

37

must be met in order for the package to be recommended for adoption. Appendix 10 sets out a sample check list for information.

7.3.5 The choices open to the Commission are to be pioneers in the field, col­ laborators in development, or adaptors. In the field of communications and data base systems the costs of development are too high and in any event major pres­ sures for improvement and development of large scale data base/communications general purpose software will continue to come from better financed areas such

as space technology. This is not to deny that some specific problems may require a commitment in these areas from time to time. Accordingly, in these areas the Commission should generally be an adaptor.

7.3.6 In terms of health care application systems the Commission will need to fill the three roles of pioneer, collaborator and adaptor. In the first instance, some available hospital computer packages will undoubtedly be suitable for use by adaptation. Secondly, there is already significant development in hospital systems proceeding throughout the world by various organisations and in Australia by the Repatriation Department and the State Governments in Public Hospitals. The Commission should arrange to collaborate with other developers where it appears practicable and desirable, but in particular, with other developers in Australia. A ready vehicle for such collaboration has been established under the auspices

of the Hospital and Allied Services Advisory Council (paragraph 4.7.9 refers). Finally, it is understood that the Minister for Health has indicated his desire for the A.C.T. hospital programs to be the best model for regional computerisation to be encouraged in the States, pending the overall development of National Medical Records Linkage. To this extent it may be necessary for the Commission to under­ take a pioneering role, especially in the broader aspects of Regional Health Care delivery and Medical Record Linkage via computer. This work should be co­

ordinated as far as practicable with any activities of other co-ordinating authorities in this field. In pioneering and, to a lesser extent, collaborative projects, the Com­ mission should acknowledge the attendant risk factors associated with develop­

mental activities. It should not be anticipated, therefore, that all projects will meet with unequivocal success and due allowance should be given to this aspect in planning.

7.3.7 There is no complete and viable fully integrated hospital health care com­ puter system available as a product anywhere in the world at this stage. However, many people are working on the problem and it is possible that such a system may emerge in due course. In the interim, there appear to be many segments or stand-alone programs available to meet the needs in hospital sub-system areas. Examples of this are Admissions and Discharge Systems, Laboratory Support Systems, ECG Monitoring and Physiological Support Systems, Hospital Facility Scheduling Systems, Pay and Personnel Systems and Accounting Systems.

7.3.8 It is considered desirable for the Capital Territory Health Commission to evaluate, and, where appropriate, to use such sub-systems when:

they are addressed to areas which are regarded as common problem areas throughout the world and the packages available indicate significant advan­ tages to the hospital administration and for patient care; and

38

early experience in hospital computer systems can be gained by all hospital staff, by direct contact or association, in preparation for further developments in this field.

7.4 Computer accommodation

7.4.1 The computing equipment acquired by the Commission will need to be housed in appropriate accommodation, and the requirements will vary enormously depending on the characteristics of the particular equipment. At one extreme mini­ computers present few problems as they are not demanding in terms of space and environment, even to the extent of not requiring air-conditioning in some cases.

At the other extreme, the powerful facility mentioned earlier in this chapter as being necessary to allow development of priority applications by the Commission will require sophisticated accommodation. Computers of the type and size envis­ aged, and the accompanying peripheral equipment especially, must be housed within specified tolerances of temperature, humidity and cleanliness. Among the

aspects requiring consideration are the question of centralised or dispersed facilities, layout and design, air-conditioning, environmental control, magnetic media storage, fire and flood protection, security and maintenance and accommodation for com­ puter room staff.

7.5 Computer staff requirements

7.5.1 Senior computer management

7.5.1.1 Given the scope of the Commission’s activities and the heavy reliance that will be placed on modern and well-planned computing facilities and tech­ niques designed to meet the current and emerging trends in health care delivery, the Commission will need to establish as a matter of urgency suitable senior posi­ tions in the Computer Services area and to recruit top-class professionals to fill them. A Second Division position should be sought, supported by two senior Third

Division positions. Considerable advantage is seen in the establishment of a further senior position to be filled by a medical practitioner who also has computing ex­ perience. This position will not necessarily be within the Computer Services Group but might be attached to that group on a permanent basis. In view of the range of activities in both the administrative and health care fields, it could be expected that the question of task and equipment acquisition priorities would be a major one. Under these circumstances, it is considered that such priorities should be determined by the Commission. It is also clear that in many respects the nature

and quality of health care delivery that can be provided or anticipated will be determined, in large measure by the nature and responsiveness of computer based facilities which are available or capable of development. The chief Computer

Services officer should therefore be responsible for providing direct advice to the Commission in these areas. This does not obviate the need for an appropriate Steering Committee as referred to elsewhere in this Report.

7.5.1.2 In relation to the support positions, it is considered that one of the two senior Third Division positions could assume responsibility for such areas as strategic design, applications and services, whilst the other would be responsible

39

for installation planning, computer operations, software, standards, control systems and training.

7.5.1.3 In seeking classifications of this order, due cognizance has been taken of the patterns and approach adopted in Australian Public Service Departments in relation to ADP organisations and in particular the approach which is taken to the provision of ‘lynch pin’ positions. The Committee has also taken into account the wide scope of activities which must be encompassed if co-ordinated health care systems are to be developed and implemented, and the increasing reliance in terms of quality and integration which is placed on computing techniques in the health care delivery area throughout the world.

7.5.1.4 The Commission would be unlikely to attract the calibre of people essen­ tial to the achievement of planned objectives in the formative and implementation years if it were to offer classifications which were not in accord with the views expressed above.

7.5.2 Programming staff

7.5.2.1 Any attempt to establish a comprehensive ADP organisation from the outset may not meet with success. The limited availability of suitable personnel would render such a task most difficult. In addition, the need to establish a firm basis for on-going recruitment and the nature of the tasks which will emerge at the outset indicate the desirability of a phased approach to organisation develop­ ment. Nevertheless, an adequate number of key positions should be obtained as soon as possible to support the senior staff indentified above in relation to existing applications and essential extensions including:

Payroll and other selected systems.

Systems studies in areas designated as priority areas.

Activities directed towards the preparation of hardware and software speci­ fications for computer equipment and accommodation.

Training activities particular to the Commission’s function; and Communications and Data Base facilities.

The requirement to meet additional functions will emerge as the Commission’s ADP potential develops. Additional capacity to meet such requirements should be established as each requirement is identified.

7.5.3 Other staff

7.5.3.1 With the development of the ADP function in the Commission, supporting personnel of various classes will be required. These will include Computer Room Management, Computer Operators, Trainee Programmers and Operators and vari­ ous types of clerical support staff.

7.5.3.2 To the extent that computers must be interfaced with medical monitoring and other specialised equipment, advice and assistance from appropriately-trained professional staff will be essential.

40

CHAPTER 8—PROVISION OF RESOURCES

8.1 Introduction

8.1.1 Previous chapters have defined the computing needs of the Commission and described the resources required to satisfy those needs. Aspects to be considered in the acquisition of those resources and the necessary accommodation and staff support will now be examined.

8.1.2 The Interim Report of the Committee recommended the use of computing systems developed in the fields of pay/personnel, creditor/general ledger, assets register and preventive maintenance, by the Computer Studies Group of the Hos­ pitals and Charities Commission of Victoria. The Interim Report also recom­

mended that as soon as practicable these systems be converted for operation on a Canberra-based facility operated and administered by the Australian Government or one of its agencies.

8.2 Interim facilities appropriate to initial operation of the Commission

8.2.1 A range of hardware equipment facilities currently in operation in Can­ berra might be considered for use by the Commission, for operation of these converted systems. Nonetheless, as indicated below, it would appear that the Commission would be afforded the greatest range of choices by arranging conver­

sion of the systems to operate on equipment of the type operated by the Welfare Group of departments. The Departments of Health, Social Security and Treasury and (although currently based in Sydney and Melbourne) the Repatriation Depart­ ment all administer and operate computing equipment of the same type. This provides a range of organisations which could be approached by the Commission. Computing facilities suitable to the task are also available in a number of other

areas outside Canberra should it be considered necessary to arrange additional fall-back facilities. It should be stressed that the possible availability of requisite computing capacity from any of these organisations has not been canvassed. This is considered to be a matter for the Commission after its formation.

8.2.2 Notwithstanding the range of installations which could be approached, the Committee noted the close affinity which is expected between the Commission and the Department of Health during the Commission’s period of establishment, the relationship of both bodies to the Australian Minister for Health and the physical

proximity of both organisations. The Commission might therefore consider that its first approach on this matter should be to the Australian Department of Health at a time appropriate to the recommendations contained in the Interim Report.

8.2.3 In considering responses from any organisation approached, the Commis­ sion should bear in mind the following significant factors:

The logical product of the conversion work to be undertaken will be the imple­ mentation of production systems which will have routine time requirements. In consequence, any arrangement concluded between the Commission and the organisation concerned should be based on assurances relating to the avail­

ability of the requisite facilities for the planned period of use. Any provisos or limitations on the use of the facilities must be clearly identified at the outset.

41

The use of particular equipment will raise the question of future commitment to identical or compatible equipment. The Commission’s staff should ensure that appropriate measures are taken to preserve the Commission’s options in its future choice of equipment.

8.3 Interim facilities for developmental work

8.3.1 An earlier chapter indicated the need for an early commencement of devel­ opmental activity in selected areas. The servicing of ‘converted’ Monash adminis­ trative systems and the need for systems development can be regarded as mutually exclusive matters and hence subject to separate consideration by the Commission. Nevertheless, there are significant advantages in employing the same facilities for both activities. The Commission should therefore consider inclusion of its require­ ments for developmental work in any request it makes on the organisations refer­ red to in the preceding section. Fragmentation of developmental effort and systems maintenance support across major equipments of more than one manufacturer will no doubt increase the problems of staff training, interchangeability of per­ sonnel across projects, etc.

8.3.2 Attention is drawn to the fact that any ADP work undertaken by the Commission in the field of health care delivery systems may have relevance to the responsibilities of other Departments or Authorities. In particular, collaboration in developmental work between the Departments of Health and Repatriation and the Commission, could prove to be of mutual benefit.

8.3.3 Consideration has also been given to the possible use by the Commission of the facilities of the Systems Development Institute administered by IBM in Canberra. The Institute provides a unique research and development facility in this country. In view of the Institute’s charter, location, general skills level and its experience in certain aspects of health care delivery, the possibility of the Com­ mission joining with the Institute on specific projects designed to provide a basis for subsequent strategies should be explored. Joint activity by expert personnel in the Commission and in the Institute could prove a valuable adjunct to general

developmental activity initiated by the Commission. It should be emphasised, however, that any approach to the Institute initiated by the Commission ought to be made on the expressed understanding that any joint activity undertaken would not constitute a commitment for future acquisition of IBM equipment or services.

8.4 Preservation of options

8.4.1 The Commission should be careful to ensure that any developmental com­ puter work undertaken during the interim phase leading up to its own equipment acquisition does not unduly influence the ultimate selection of this equipment. The retention of its ultimate selection options could be facilitated by clear and

common standard design specifications, the use of a standard programming langu­ age such as COBOL and, in the main, restricting work on the major functions as far as possible, to developmental and pilot stages. The Commission should recog­ nise however, that the use of any particular equipment prior to the selection of its own facilities can serve to place the equipment manufacturer concerned in a position of relative advantage during subsequent equipment evaluation.

42

8.5 Commission facilities

8.5.1 General considerations

8.5.1.1 The Commission should commence, as soon as possible, longer term planning directed towards acquisition of a suitable central computing facility, appropriate to its foreseeable needs. This task will follow definition by Commission personnel of those applications to be developed and implemented and determina­

tion of the cost benefit position. It is assumed that these definitions will be based on consideration of economic and social acceptability and suitability of potential computing applications in the medical field in the Australian Capital Territory environment. Hardware- and software-oriented tender specifications should be pre­

pared on the basis of the Commission’s requirements and the hardware/software characteristics proposed by the Committee (see Chapter 7).

8.5.1.2 For reasons of both longer term co-ordination on the national level and the very broad spread of functions and nodes of health care delivery and support, it will be essential for the Commission to centrally co-ordinate and control the

acquisition of all computing equipment and development in the Australian Capital Territory health care field. In addition, the Commission must establish the stand­ ards to be applied in computer development and operations under its control, and establish machinery to ensure that they are followed and maintained.

8.5.2 Hardware acquisition

8.5.2.1 It would appear that the Commission will be given the power to acquire (by purchase or lease) and store such equipment as is necessary to conduct all its functions. It is not known whether these acquisition procedures will include provisions relating to public tender. It would seem, however, that the enabling

legislation or ordinance will allow the Commission to proceed with equipment acquisition without the mandatory involvement of the Australian Government Stores and Tender Board.

8.5.2.2 Such an arrangement would tend to increase the Commission’s flexibility in equipment acquisition and expenditure programs. However, in view of the competitive environment and rapid development of computing hardware and the current and prospective developments of software in the health care field generally,

the procedure of open tender appears particularly appropriate to the purchase or hire of computing equipment and ancillary facilities.

8.5.3 Relationship with Australian Government Stores and Tender Board

8.5.3.1 It should be noted that, in conjunction with Departments, the Australian Government Stores and Tender Board has been actively associated with a large number of computing-equipment and related acquisitions over a number of years. This period has seen a steady development in the scope and suitability of Aus­

tralian Government contracts in this field. The Commission should endeavour to gain by this experience in exploring with that body the possibility of gaining access to selected, recently-negotiated contracts broadly suitable to the Commission’s needs. The onerous and complex burden of contract formulation and negotiation

43

would no doubt be reduced in consequence. It should be noted that most suppliers have available a ‘standard’ type contract which they offer for consideration. Gen­ erally speaking, such contracts have been found to be unacceptable from the Australian Government’s point of view.

8.5.4 Relationship with the Interdepartmental Committee on Automatic Data Processing

8.5.4.1 It is also possible that in contrast to the procedures in operation for each Australian Department and certain Authorities, there will be no obligation on the Commission to seek the concurrence of the Interdepartmental Committee on Automatic Data Processing to any systems or equipment acquisition proposals which it formulates. However, in view of the Interdepartmental Committee’s long experience and its strong association with bodies involved in well-established ADP operations, it is recommended that the Commission keep the Interdepartmental Committee informed of its plans and strategies in the processing field and seek the Committee’s advice.

8.5.4.2 The Commission’s officers should seek to obtain, through the Interdepart­ mental Committee Secretariat, equipment specifications and other documentation which might be of value in the formulation of equipment and software specifica­ tions, bench marks, acceptance testing procedures, etc., encompassing the range of facilities to be sought by the Commission.

8.5.5. Multiple suppliers

8.5.5.1 Over the last few years the number of active computer equipment sup­ pliers has increased considerably by the addition of several firms offering equip­ ment compatible with that supplied by the major or traditional manufacturers of equipment hardware (e.g. IBM, CDC). By far the best-developed ‘plug compatible’ market sector relates to the IBM System 360 and 370 equipment range. Ampex, Itel, CDC, AMS and Telex are among many of the well-established firms which have entered the field. In addition, a number of leasing companies offer ‘second­

hand’ reconditioned computing equipment. Once again this marketing activity has tended to focus on IBM equipment.

8.5.5.2 With both ‘plug compatible’ and re-conditioned facilities, the units of equipment concerned can be obtained at prices substantially lower than those specified by the major supplier for the equivalent units. In certain cases the ‘plug compatible’ equipment is offered with facilities superior to the product it replaces. It might appear, therefore, that the opportunity does exist for the Commission to achieve savings if more than one supplier was to be involved in the equipment procured for any one system. ‘Plug compatible’ equipment has recently been acquired by the Department of Health and by the Atomic Energy Commission with the advantages of lower cost and increased productivity. It should be noted that both these organisations are experienced users, but nevertheless the installation and operation of ‘plug compatible’ equipment has not been without difficulty in both technical and contractual fields. For practical purposes the ‘multiple supplier’ installation must still therefore be regarded as in the proving stages in this country.

44

In consequence, this arrangement is not recommended for the initial stages of ADP installation development in the Commission. The principle of single supplier per system class is recommended. As the Commission gains strength in the field and can observe experience elsewhere, it may care to review this situation.

8.5.6 Systems of differing size and functional use

8.5.6.1 The variety of requirements which exist and will develop in the A.C.T. health care delivery environment may call for a variety of facilities ranging from process control and other mini-computers on the one hand to a powerful, medium-

scale facility on the other. Well-developed markets exist in each of these com­ puter classes. The comments in the previous paragraph refer specifically to equipment and peripherals comprising a ‘system’ in any one class and should not be taken to imply a recommendation for supply of all classes of computing equipment from a single supplier. Such a course would be neither practical nor desirable. It should be borne in mind, however, that the need for inter- and intra­ systems communication of various kinds will increase as the health care delivery scheme develops. The question of current or potential compatibility would there­ fore be an important criterion for equipment selection in certain cases.

8.5.7 Cost of equipment

8.5.7.1 The capital costs of central computing equipment appropriate to the fore­ seeable needs of the Commission cannot be ascertained until requirements have been detailed, specifications for equipment and associated facilities prepared and quotations or tenders received. Nevertheless, it was considered that it may be

useful to provide some order of magnitude of cost so that the processing needs of health care delivery in the A.C.T., as perceived by the Committee, may be placed in perspective. The deliberations in this matter are in no way intended to pre-empt the responsibilities of Commission staff associated with the development

and introduction of the system. Attention has been largely confined to the poten­ tially powerful central facility referred to in the previous chapter, as this would be the most significant item of capital cost in the information-processing system.

8.5.7.2 The Committee’s considerations indicate that the cost of the central facility could be of the order of $2-0m to $2-5m. This assessment is based on the expected foreseeable needs of the Commission insofar as they impact on facilities at the central location. It would be expected that the capital outlay for the central

facility could be appropriately staged through time, in accordance with an ordered strategy for systems developments and progress with these developments. The cost assumes extensive use of on-line techniques and facilities linking a number of seg­ ments in the health care delivery system with the central facilities. The figure also includes the cost of a substantial amount of equipment duplication ($900,000

approx.). This duplication of equipment would not only serve to improve general systems reliability, but under normal circumstances, would meet the needs of systems and software development and proving activities. This would ensure that such activities could be carried out with a minimum of disruption to systems in operation. The cost assessment was made after broad consideration and pricing

of model configurations of computing equipment.

45

8.5.8 Equipment maintenance 8.5.8.1 It will be necessary for the Commission to enter into maintenance agreements covering any computing system it acquires for the selected period of amortisation of the equipment concerned. Most equipment manufacturers offer appropriate maintenance services directly and the Commission is urged to arrange maintenance for at least an intial period through this source, if available. Equip­ ment specifications should spell out the nature of maintenance facilities required from the contractor.

8.5.8.2 Independent organisations have recently emerged which offer maintenance services across a range of manufacturers’ equipment. Experience to date indicates, however, that at this time general deficiencies in numerical strength, depth of experi­ ence and skills in these independent organisations render the use of such services inappropriate to the support requirements of a new user unless the recommended alternative is not available. This is particularly so with the medium to large-scale installation. The Commission could, however, profitably review developments in maintenance provisioning from time to time.

8.5.8.3 As in the case of purchase contracts, the quality and suitability of com­ puter equipment maintenance contracts finalised by the Australian Government Stores and Tender Board have developed to a high standard over the years. Commission officers are advised to seek access to recently negotiated maintenance contracts through the Australian Government Stores and Tender Board to ensure appropriate coverage and to reduce the resources which would otherwise be involved in developing a suitable maintenance contract ab initio. It should be noted that purchase and maintenance of computing equipment in the Australian Public Service are invariably covered in a single specification but are subsequently the subject of separate contracts. The Commission would obtain maximum flexi­ bility in responding to any cost-effective developments in the maintenance area in this country if it was to adhere to this general practice.

8.5.9 Software acquisition

8.5.9.1 Each equipment manufacturer offers a basic set of general purpose pro­ grams which are either essential to the operation of the computer and its periph­ erals or the performance of particular functions or which are designed to perform certain tasks of a general purpose nature. The essential characteristics of this software should be set out in the equipment specification and demonstrated satis­ factory performance of this software should be a basic criterion for equipment evaluation, selection and acceptance.

8.5.9.2 The previous chapter dealt in some depth with additional software which is of relevance and value in the health field. Proven teleprocessing and data base management facilities should be regarded as mandatory on the supplier of the major computing facility referred to above. The minimum facilities sought in both of these software areas should be identified and set out in the specification document. The suitability of facilities offered to the needs in the A.C.T. should be given weight in the equipment evaluation process.

46

8.5.9.3 It is also considered that the specification should seek detailed advice on any health care support systems which the equipment manufacturer is able to offer. Appendix 10 contains a minimum set of criteria against which any responses should be considered. Suitable user software of significance should be regarded as

important in the equipment evaluation process. Teleprocessing and data base management software' and hospital application packages are available from a number of sources, for example:

Computer Manufacturers: Most of the major computer manufacturers have available Teleprocessing and Data Base packages and a proportion of them have hospital application programs. As mentioned above, the availability of such packages should be determined when considering the question of hard­

ware selection.

Independent Software Houses: This is another source of computer program packages which may be appropriate for various aspects of the hospital and health care environment. In these cases, more attention is necessary to the question of the stability of the company and its capacity for longer term sup­

port. Costs and rights in ownership are also important. In addition, many independent software houses aim their product at a particular hardware manu­ facturer’s equipment and it may not be suitable for other equipment.

Overseas Hospitals, Health and Service Agencies, etc.: Many organisations which have developed their own computer packages for processing hospital data are willing and anxious to have their systems used by other installations. Normally, access to these sources is only available through personal contact

and approach.

Australian Hospital Authorities: As described in Chapter 4, HAS AC consti­ tutes a suitable vehicle for access to details of any hospital or health care system operating or being developed at present in Australia.

8.5.9.4 There are two alternatives available from the use of package programs, either exclusively, or in part. They are ‘in-house’ development or contract product delivery by consultancy-type firms.

8.5.9.5 In-house development is very much dependent upon the acquisition of skilled and experienced staff to undertake this work. A nucleus of such staff will be necessary in any event, but the size, structure and pattern of acquisition, includ­ ing training, can only be determined on the basis of the schedule and priority of

tasks it is required to undertake, and the general strategy of development which is elected. The skills and experience of such staff can be leavened with consultancy staff on a work project basis.

8.5.9.6 Products developed and delivered under contract by consultancy-type firms pose many difficulties. Normally, to ensure that the contracted product is delivered as specified and on time, a significant level of ‘in-house’ competence is required. Skills are necessary to specify the contract product in detail and to

monitor its development and progress. However, the use of consultancy-type firms in this manner should not be overlooked where the task can be clearly identified and unambiguously specified. This topic is expanded on later in this chapter.

47

8.6 Accommodation for Commission facilities

8.6.1 It is understood that in reference to the Capital Territory Health Commis­ sion, Cabinet has been asked to consider, inter alia, the question of Capital Works. The crux of the Cabinet Decision in this matter was that funds for Capital Works for the Commission should be appropriated to the National Capital Development Commission and included in the Development Commission’s Works Program. In

addition, a Standing Committee on Planning and Construction, comprising officers of both Commissions would be established for the purpose of:

admitting Commission requirements to the Works Programme in time to meet target dates for decision making;

involving the Commission in the selection by NCDC of agents and consultants for Health projects; and

ensuring participation by the Commission in those aspects of town planning relating to the provision of health services.

8.6.2 It should be noted that no specific mention has been made of the Depart­ ment of Housing and Construction, although in accordance with normal practice, the National Capital Development Commission would no doubt involve that Department in certain of its construction activities. The planning and preparation of computer accommodation is a protracted and complex matter involving sub­ stantial lead times. In these circumstances, it is recommended that planning activi­ ties in this area should be commenced at an early date. The Department of Housing and Construction now has considerable experience in the field of computer accom­ modation planning and servicing and could be most valuable in a consulting capacity even if the Commission’s intention was to arrange construction through

private contractors. As an ancillary step the Commission should seek at an appro­ priate time access to specifications covering such areas as layout and design, construction, air-conditioning, environmental control, fire protection, security and maintenance. Such documentation would no doubt be of considerable assistance to the Commission’s staff in dimensioning the problems ahead of it.

8.7 Technical personnel

8.7.1 Initial staff acquisition

8.7.1.1 The Commission will need to obtain appropriate persons to fill its Senior ADP Administration and Medical Advisor positions, and subsequently recruit trained ADP staff to fill its initial key positions and meet its medium term expan­ sion needs at least. Recruitment action should be initiated at an early stage. If

the ADP positions are to be encompassed by the provisions of the Public Service Act, recruitment action can be a longer process than in a ‘hire and fire’ environ­ ment. However, it is possible that the subject matter area and the role of the

Commission generally could attract personnel who have a special interest in hospi­ tal and health care systems. The overseas market should be examined closely and the facilities of the Public Service Board Representative in London might be used. The conditions of employment of Commission personnel may also enable recruit­

ment of North Americans. Residents of the United States normally will not sacrifice their citizenship to join the Australian Public Service.

48

8-7.1.2 Pending the establishment of its own Computer Services group on a functional basis the Commission might consider seeking further assistance from the Department of Health by requesting a continuation of the services of ADP officers currently seconded within the Department to work exclusively on matters associ­

ated with the planning of ADP servicing for the Commission. Consideration might also be given to the prospect of seeking further ADP personnel support from the Department through this interim period. A complementary approach to the Repat­ riation Department for consultative advice as required should also receive con­ sideration by the Commission.

8.7.1.3 Substantial development in the field of automated health care delivery systems is occurring overseas. Urgent consideration should therefore be given to the question of key personnel from the Commission visiting selected installations overseas to bring their studies up-to-date, to gain exposure to any resource-saving techniques or facilities and to examine evolving techniques for improving the efficiency and quality of health care delivery. Potential overseas recruits might also be interviewed during this visit.

8.7.2 Consultants and contract programmers

8.7.2.1 The Committee has considered the possible use of ADP consultants on a commercial basis by the Commission. ADP consultant firms which are con­ tracted to develop and implement a system of any size in its entirety, require a

high degree of project specification and progressive approvals to proceed on the basis of landmarks achieved. This necessitates considerable attention to progress monitoring. Invariably these factors increase in importance with the size and complexity of the project and can therefore be expected to be of significance in most of the areas of concern to the Committee. In consequence the Commission should discourage employment of consultant firms in this manner, at least until it has its own experienced staff who are capable of preparing clearly defined speci­ fications in a form which can be the subject of appropriate contractual cover and who possess the capability to checkpoint and monitor progress and achievement.

8.7.2.2 An alternative to the use of consultant firms under contract on a project- oriented basis is to exploit the talents of their staff on a ‘contract programmer’ basis. Under these circumstances, skilled personnel would be made available at a daily, weekly or monthly rate from an experienced ADP firm to work with, and at the direction of appropriately experienced Commission staff. In this case, the personnel engaged may be merged with the organisation’s own personnel to undertake any task in hand. As the consultant firm is not associated contractually with a particular project, the employing organisation has the flexibility to reallo­ cate the consultant’s staff across suitable projects in accordance with changes in priority. This method of external recruitment has been employed successfully by the Department of Health over the last 18 months. It has proved to be an invalu­

able means of providing additional resources which can be used fruitfully to accommodate peaks in work demands and to mitigate against the effects of delays in recruitment of the organisation’s own personnel on a permanent basis. It is proposed that the Commission should explore closely this avenue of obtaining resources. Details of the mechanism and the related arrangements adopted in the

49

Public Service for the acquisition of consulting services can be made available, if required, from the Public Service Board. However, the Commission may find itself, through its conditions of employment, in a more flexible position than that indicated by the arrangements applicable to the Public Service Departments.

8.7.3 Computer operations staff

8.7.3.1 Computer operations staff should be acquired to coincide with a planned future date for computer acquisition. Recruitment should be effected not less than 9 months prior to such a date. Arrangements for in-depth training at an installa­ tion operating equipment similar to that to be acquired by the Commission should be arranged through the interim period. It would be helpful, however, if an experi­ enced computer room manager was obtained at an early stage to assist with the very many tasks associated with computer room planning and the acquisition of essential ancillary equipment and consumables.

8.7.4 Trainee programmers 8.7.4.1. Basic training of programmers requires at least 12 months. Thereafter, their work contribution improves as they benefit from practical experience in the field. At least 3 to 4 years of experience are necessary before a fully-skilled re­ sponse could be expected over the total range of computing requirements. The Commission should plan accordingly and introduce measures now to mitigate against the problems of recruitment in the future. The Commission should there­ fore seek to recruit 3 or 4 trainee programmers for the 1975 academic year. The Australian Public Service Programmer-in-Training scheme appears to be a very adequate vehicle for accommodating these recruits and programmer trainees re­ cruited in the future, although direct recruitment from groups of personnel engaged on appropriate courses at Colleges of Advanced Education should be considered. In any event, it is unlikely that the Commission will be in a position to handle the practical aspects (e.g. on-the-job training) of its first year trainee intake. An approach could be made to any one of a number of Departments to handle this matter on the Commission’s behalf. The Department of Health, the Department of Social Security and the Repatriation Department each have a well-established,

efficient and co-ordinated training course.

8.7.5 Ancillary support staff 8.7.5.1 No difficulty is seen in recruiting clerical and non-technical personnel as required but appropriate training will be necessary for those not previously ex­ posed to ADP before these people can become fully productive. It should be recognised, however, that a number of computer-based administrative systems are in operation or will shortly be introduced into the areas which will be controlled

by the Commission. Adjustments to the duties of existing clerical positions may therefore be appropriate, at this stage.

8.7.6 Steering Committee .

8.7.6.1 Multidisciplinary involvement in both project evaluation and development is considered essential to the successful operation of the Commission’s Computer Services group. Any decision to develop and implement a computer system should

50

ideally be made against a background of enthusiasm and initiative by the user areas involved and this can best be achieved by their active participation in all phases of planning, development and review. To this end the establishment of a Steering Committee comprising representatives from medical, nursing, paramedical,

administrative and computing disciplines appears most desirable. Such a Commit­ tee, which need not be large, but should have powers to co-opt as required, should be charged with advisory responsibilities on matters relating to overall policy, developmental priorities and periodic reviews of progress.

51

CHAPTER 9—STRATEGIC ASPECTS OF INSTALLATION AND SYSTEM PLANNING

9.1 General considerations

9.1.1 There are three separately identifiable, but nonetheless closely related, criteria which must be at the core of any competent system design. These are:

(a) reliability of the system; (b) security of information; (c) accuracy of computation;

and each will receive individual attention later in this chapter. Undoubtedly these criteria deserve special consideration in areas of health care and administration although the temptation to over-dramatise their importance and argue that failure of the computer system might threaten the very life of the patient should be avoided. It is hard to imagine, in the foreseeable future that the computer will effectively assume the clinical decision-making role to the extent of obviating the need for physician intervention; rather, the computer will continue to play a supportive part and the final diagnostic and therapeutic decision-making responsi­ bility will remain with the physician. Even in those areas such as intensive-care monitoring where the patient-computer relationship is accentuated, the computer’s role is to record and advise on exception limits and the failure of the computer system in such a situation would merely entail a reversion to ‘manual procedures’ and a heavier reliance upon observation by medical and nursing staff. In passing, one might note that in areas such as patient monitoring, accuracy of computation assumes an overwhelming importance.

9.1.2 Notwithstanding what has been said, system reliability and security is still of paramount concern and deficiencies in this respect might well lead to any of the following undesirable situations.

(a) A reduction in the level and/or quality of clinical support with conse­ quent deterioration in the standard of health care delivery, perhaps to a point of unacceptability.

(b) Gross impairment to other patient-oriented functional areas which receive computer support, resulting in inadequate patient servicing and deteriora­ tion in the level of care and treatment.

(c) Curtailment of administrative functions (e.g. payroll) and the attendant risk of staff discontent and organisational difficulties.

(d) Disruption to computer-based communication facilities, again down­ grading the standard of health care and probably causing acute frustra­ tion amongst operational staff.

(e) A reduction in the capacity to undertake evaluation studies, long-term planning programs or clinical research activities through the non­ availability or the suspect nature of information committed to computer.

9.1.3 Whilst this rather intimidating list of possibilities might at first sight, argue for a rather cautious approach by prospective systems implementers, it would be

52

fair to add that none of the problems referred to are really exclusively confined to medically-oriented systems and all have been and can be satisfactorily handled by careful systems planning and design.

9.1.4 Although 100% hardware reliability is an unattainable objective it is none­ theless entirely feasible to reduce the probability of systems failure to negligible proportions. However, since the costs of computer configurations possessing a high level of equipment redundancy tend to increase disproportionately as the overall reliability approaches 100% (exemplified perhaps by the manned space­ craft control systems) it is necessary to seek other means of system survival during

periods of planned or impromptu computer or system breakdown. Clearly, the ability to fall back to manual procedures offers an economically attractive solution and although the function may be degraded to some extent during the period of reversion, adequate planning should prevent the level from falling below acceptable

norms.

9.1.5 It is important to acknowledge that, particularly in the field of real-time processing manual fall-back procedures constitute the final level of support during a period of system failure and that it almost certainly will be necessary to revert to these procedures from time to time during the lifespan of the system. The design and specification of these procedures should therefore be considered in parallel with system development. It is not sufficient merely to resort to those manual

procedures which existed prior to introduction of the computer system, since it is unlikely that they will be completely compatible with then existing objectives and information requirements and in any event would require the wasteful mainten­ ance of dual systems. New procedures must be defined which allow operational

staff to make a systematic and orderly change, which minimise resource overheads during the period of the failure and which permit efficient and unhindered restora­ tion of the computer system including subsequent entry of transaction data occur­ ring during the period of the failure.

9.1.6 The system designer is therefore faced with the problem of striking the right balance between a high configuration reliability with its associated high cost and an acceptable level and duration of degraded systems performance. This bal­ ance will vary from application to application and should be assessed individually, although when several systems must share the same computer resources then, of

course, the application demanding the greatest reliability will probably determine the level of equipment redundancy.

9.2 Reliability of the system

9.2.1 Equipment reliability may be measured in terms of ‘availability’ which in turn is a function of the ‘mean time between failures’ (MTBF) and the ‘mean time to repair’ (MTTR). More precisely MTBF

Percentage Availability = ----------------------- X 100

MTBF + MTTR

9.2.2 Unfortunately computer manufacturers are notoriously disinclined to offer definitive reliability figures so that the systems planner is forced to resort to advice

53

from other users or to use his own estimates. Suffice to say that given estimates of reliability for each component unit of a computer system, a fairly simple analy­ sis will reveal the total system availability. Reconfiguring to obtain optimum reliability can then be conducted in a scientific rather than haphazard manner.

9.2.3 Clearly, system reliability can be improved by introducing a degree of equipment redundancy, that is, by duplicating certain critical components, but the method of interconnecting this equipment will affect overall reliability. Such configurations as duplex, twin, load-sharing, shared file and satellite/parent all tend to enhance overall reliability to varying extents and with varying equipment costs.

9.2.4 Although a closer study of reliability estimating would be inappropriate here, it is important to stress the differing requirements between batch processing and real-time systems. A hardware malfunction in a batch environment, provided it is not too protracted, usually results only in delay, and prudent scheduling can safeguard against this possibility. At worst the outcome might be a level of incon­ venience. Real-time systems on the other hand, which imply a high level of inter­

action between the system and the user, are far more vulnerable to machine fail­ ures and even relatively short term failures might disrupt organisational or control activities to such an extent as to demand alternative back-up facilities. Looking for parallels outside the medical field one can readily envisage the results of a two hour breakdown in an airline reservations system or a refinery plant process con­ trol system. The first would undoubtedly lead to loss of revenue and the latter perhaps to complete plant shutdown.

9.2.5 It is pertinent to consider types of systems failure which can occur and examine the methods of both reducing their probability and handling them when they do occur.

(a) Transient or momentary failures These might be caused by equipment malfunctions, power surges, loss of power, etc., and whilst they inevitably result in cessation of programs currently running, systems may be designed to include automatic restart facilities which enable them to self-resurrect in a relatively short time. In addition, computer systems of any size are normally supplied with efficient voltage regulators and an alternative independent power supply can be established to cater for failures in this respect.

With the precautions mentioned above it is unlikely that the incidence of transient failures is likely to be sufficiently high to cause any embarrass­ ment even to real-time systems operating in the hospital/health care environment.

(b) Failure of a peripheral component This type of failure which might relate to a disk-drive, tape drive, printer, terminal, etc., is usually rectified by replacing the faulty equipment. This may be achieved by physically substituting the new item of hardware, by utilising manual switching devices or, in current generation systems, by

54

invoking dynamic hardware reconfiguration procedures where the oper­ ating system itself reorganises in order to bypass faults.

Peripheral component failures are therefore handled by ensuring an ade­ quate reserve of back-up equipment and developing procedures for effi­ ciently bringing them into operation when required. Alternatively, during

periods of component failure it may still be possible to offer a service, albeit degraded; for instance a real-time system may be so designed that the collapse of a component (e.g. disk-drive) would not cause the entire system to come to a halt, but might result only in a slowing-down in

response times.

(c) Failure of entire system

Such failures are normally caused by either a failure in a critical hard­ ware component (e.g. central processor) or a critical software item (e.g. operating system). They may result in short-term outages, or in some cases prove more serious. The duration of the outage will in large mea­

sure depend on the responsiveness of the maintenance arrangement. Although it would be fair to say that the use of improved circuitry tech­ niques, error correcting codes, automatic instruction re-try, etc., has reduced the incidence of such hardware failures in current generation

equipment, it is nevertheless important to protect against them. Along with equipment failures it is also important to appreciate that all system components must receive scheduled preventive maintenance. This is usu­ ally carried out during ‘dead shift’ periods but since certain hospital systems may be required to be operational for 24 hours each day the

need for preventive maintenance becomes analagous to a system failure.

Failures of this type may be handled in one of two ways. Either alterna­ tive facilities may be switched in or, for the duration of the ‘fault’, operational staff must resort to manual procedures, and, at such time that the system again becomes operational, the back-log of transactions must

be entered. The use of optical character recognition or mark sensing input devices possesses particular merit in this respect since input data forms are both man and machine readable and transaction back-logs in

certain areas can be cleared relatively quickly.

(d) Catastrophes Fire, flood, tempest, vandalism and militant interference are all areas which demand particular consideration in planning the computer installa­ tion. It is vital to protect and insure against these contingencies since

remedial plans, even if practicable, will only marginally lessen the trauma of such an occurrence.

Accidental hazards such as fire and flood can be guarded against by careful site planning and by incorporating adequate measures for fire protection, detection and suppression. The question of minimising these risks should be taken up with the Department of Housing and Construc­ tion at an early stage of installation planning.

55

Computers are increasingly becoming the targets for militant action by malcontents and, whilst installations supporting health care functions would appear not to offer rational motivation for hostility, it would nevertheless be negligent to dismiss the risk entirely. Installation planning should also address the problems of accessi­ bility and protection against external and internal intrusion from both the archi­ tectural standpoint and the need to establish adequate security procedures.

9.2.6 In addition to the measures outlined above, the risk of damage by fire or other hazard may be further minimised by limiting the equipment placed at any one location. In such a scheme computing power may be geographically dispersed by placing smaller computers in separate locations and providing inter-connecting links. Failure of one installation may then be overcome by switching over to another. Whilst the economies of such a solution, involving additional housing and staffing overheads, are perhaps unattractive, the location of any mini­ computer installation which might be established to service say, nuclear medicine or pathology could well be decentralised.

9.2.7 Computer room security therefore demands thorough consideration from an early stage. It will undoubtedly constitute an appreciable component of the overall installation cost and the optimum solution can only be attained by close analysis and the balancing of costs of protection against the level of each identified risk.

9.3 Security of information

9.3.1 Much of the information likely to be held in medically-orientated systems is highly confidential and must therefore be safeguarded against unauthorised intru­ sion. This subject has already received attention and will not be reiterated here except to enumerate a variety of devices and procedures which may be adopted to circumvent the possibility of intrustion, namely:

(a) the use of identification codes whereby the terminal user identifies himself to the system and in so doing determines those system facilities to which he is entitled to have access;

(b) the use of badge readers attached to terminals which essentially perform the same function as outlined under (a), but can further be used for access to restricted areas or the hospital itself and as a basis for time recording;

(c) the use of ‘scrambling’ techniques whereby data may be held on computer files in an incomprehensible manner and ‘deciphered’ by the program which accesses it;

(d) initiation of regular systematic audits of the system;

(e) the innate complexities of the system which would virtually preclude intrusion from personnel untrained in its use.

9.3.2 In addition, information which has been committed to the system must be secured against loss, destruction or corruption. This can be achieved by ensuring that files are ‘dumped’ or copied at regular intervals so that, at worst, it will be necessary to revert to the previous generation of the file and recover from that

56

point by reprocessing all the transactions which took place between the times of the previous dump and the failure. This procedure may be facilitated or obviated by checkpointing, by maintaining an ‘audit trace’ of all transactions and referring

to this in order to re-establish the file, or by more advanced recovery/restart procedures.

9.3.3 Magnetic media files (i.e. tapes and disks) must be housed in an environ­ ment secure against fire, theft and damage and ‘key’ files should be periodically copied and housed in separate accommodation geographically removed from the main storage area.

9.4 Accuracy of computation

9.4.1 Computational inaccuracy might arise from a number of sources. These are outlined below together with the preventive measures which should be taken in each instance.

(a) Undetected transmission errors Corruption of data incoming to the computer on communication lines can and does occur and the frequency of occurrence is probably proportional to the distance of transmission. However, the reliability of data communi­ cation equipment is very high and the use of error detecting and error

correcting procedures has reduced the probability of undetected errors to negligible proportions.

(b) Errors in data submitted to the system It is fairly commonplace for the terminal operators to mis-key data to the computer. This may be safeguarded against by equipping the system with comprehensive editing capabilities and using other error detection

techniques (e.g. check digits) so that incoming data can be checked for correctness of format and reasonableness of content. On-line, real-time systems must be supported by sophisticated control sub-systems providing a basis for dialogue between the computer and the terminal operator in

order to oversight the flow of data and signal errors and incompatibilities.

(c) Errors in transferring data from CPU to storage device Data transfers are closely supervised by the computer’s operating system and such standard facilities as reading and comparing after writing a record are available in most systems. The possibility of error in this

respect is very low.

(d) Program errors Perhaps the most ubiquitous of all faults, program ‘bugs’ can be guaran­ teed to reveal themselves throughout the life of the system. These errors may occur in supervisory programs or in application programs and are

usually attributable either to a program modification which has not been adequately tested or to the execution of a logical procedure which has not hitherto been attempted. Their frequency may be decreased by estab­ lishing and enforcing suitable programming standards and insisting on

57

rigorous and comprehensive pre-implementation systems check-out. Their severity may be reduced by built-in logical by-pass procedures and establishing and maintaining a high level of systems documentation to assist in maintenance activity.

9.5 Summary

9.5.1 The question ‘How will service be continued in the event of failure to any component of the computer system?’ must be addressed to each application which is considered for computer support. It will assume varying significance according to the nature of the task to be automated and the contemplated solution. Undoubt­ edly in the field of hospitals and health care, those systems which have a direct impact on the level of clinical and supportive patient care and those which are to be serviced in a real-time manner place greatest emphasis on the problem and demand the most rigorous examination.

9.5.2 Whilst a precise specification of measures to enhance reliability and pro­ cedures to withstand system failures is not possible without a close analysis of system objectives and requirements, it is nevertheless possible to postulate some of the characteristics of the computing configuration which might service the Commission and to highlight a number of areas which deserve careful and timely consideration.

(a) It is inevitable that some of the systems to be implemented will require a degree of equipment redundancy. This will certainly be so for terminal equipment and, depending on the level of reliability demanded, could extend to key components of the main computer installation.

In addition, the need to maintain a developmental capability, even when systems become operational, highlights the need for excess computing capability in a form that will not interfere with operational systems. This could well be an important factor in considering the need for duplicating the central processor and using the second machine for developmental work as well as providing back-up to the main processor.

(b) Careful attention should be paid to ensuring a secure environment for the computer(s). Risks such as fire, flood and vandalism should be appraised and precautionary measures implemented. In this respect con­ sideration should be given to the geographical separation of component

sub-systems and the potential benefits weighed against the economic overheads.

(c) Magnetic media storage areas should be established both on-site and remotely.

(d) Particularly with real-time systems and those having a direct impact on the level of patient care, provision must be made for invoking alternative procedures in the event of system failure. These may range from operating in a degraded manner through to a complete reversion to manual pro­ cedures. However existing manual procedures should be revised to ensure compatibility with the computer-based system.

58

(e) The computer installation should be protected against power irregularities and two separate and independent power sources should be sought. ‘No break’ systems are not considered to be cost-justifiable for hospital computing.

(f) Due regard should be paid to the need for both preventive and ad hoc equipment maintenance. The cost of 24 hour on-site maintenance may well be prohibitive but contracts should demand a rapid response to calls for assistance at any time of the day.

(g) Adequate facilities should be embodied within ‘sensitive’ systems to secure the confidentiality of information handled by them.

59

CHAPTER 10—TRAINING

10.1 Introduction

10.1.1 In considering this topic, ‘training’ has been interpreted in its broadest sense, and due attention has been paid to all those aspects which may be desirable or necessary to accompany the planning, development, implementation and opera­ tion of computer systems in the Capital Territory Health Commission. Although the need for systems training is a natural overhead attached to the implementation of computer systems, it assumes an even greater importance where medical and other health professional staff are involved. Established manual systems together with staff who might be opposed to change can pose serious problems to the implementation of a computer system. Instances have been recorded of proposed systems being shelved and attempted implementations having failed at least partly because of the attitude of the staff involved. Relevant education would appear to hold some of the answers to this problem, and should be complemented by maxi­ mum user participation at all stages of a project.

10.1.2 The need for public relations to promote the development of computer systems in health care delivery in the A.C.T. has also been examined. Public rela­ tions exercises are seen to be necessary to make a variety of groups aware of and gain appreciation of benefits which could be provided by computer-based systems

in the health care field.

10.2 Planning

10.2.1 Following the establishment of a Computer Services group within the Commission, early consideration should be given to the need to broaden and con­ solidate the base of expertise in the relatively new and fast-developing field of health-oriented computing. Such an investment should embrace a full appraisal of developmental work currently proceeding in this country and the establishment of information interchange channels with the relevant organisations. Ideally this might be augmented by a detailed fact-finding mission aimed at inspecting and assessing various operational medical computing systems both in Australia and overseas. Nominees from the multi-disciplinary Steering Committee mentioned in an earlier chapter could be included in such a team. The choice of installations to be visited should take into account the type and extent of systems implemented and their relevance to the Commission, based on the priorities for study and development at that stage. Installations using software and/or application packages which were being considered for use by the Commission might be of particular interest. A reasonably detailed inspection tour, preceded by suitable preparation

where possible, would greatly assist members of the Steering Committee to make future recommendations concerning the development of computer systems within the Capital Territory Health Commission.

10.3 Training and staff involvement

10.3.1 Looking firstly at the initial stages of a project, during the feasibility study there appear to be two aspects of training. The first is the education of the poten­

60

tial users in the capabilities and limitations of computers, with a number of aims in mind:

to enable the users to assist in the study by critically examining the require­ ments of their system and to help in determining whether a computer-based system would be of benefit to them;

to generate enthusiasm for the proposed system;

to generate understanding of the work involved in successful development, implementation and maintenance of the proposed system;

to encourage participation in all stages of study and development.

Computer appreciation courses are a regular feature of the training sections of many Government Departments and aids are available (such as audio-visual equipment) to assist in conducting such courses. The second aspect of training at this stage of the project is the education of the Computer Services staff who are

to undertake the feasibility study. The study will require detailed and lengthy discussions with the functional area staff (lessened to some extent if up-to-date documentation is available on the existing system). In the medical areas especially, such discussions could suffer if the Computer Services personnel had not previously

undertaken some background education in the appropriate field so that they could establish a degree of rapport with the medical staff. Such training could be ex­ pected to yield benefits in user and Computer Service staff confidence, and result in less likelihood of major setbacks in the new system.

10.3.2 Moving to the development and implementation of a system, the user training required at this stage of a project will be concentrated towards the end of the development period. The type of training necessary will depend largely on the characteristics of the developing system, particularly with regard to the user/

system interface. For example, a commercial system which only requires staff to adjust to a new form and use computer output rather than manually prepared reports, will require a minimum of user training. On the other hand, a real-time hospital system which requires medical/nursing/clerical staff to use terminals, and

eliminates some existing paper reports, will need a much greater training effort. Part of the training will be theoretical, with the issuing of user manuals, perhaps reinforced by seminars, discussions, etc. The most important part of the training,

however, will be practical. It may be sufficient to involve the users in the final stages of testing, followed by gradual implementation. However, where the system requires relatively large-scale data preparation, complex terminal work or simply extensive staff participation, system development may have to include the creation

of a computer based subsystem designed especially for user training. At the same time that user manuals are prepared, operations manuals should also be written to provide a basis for the successful operation of the system by the appropriate Computer Services staff.

10.3.3 Once a system is in operation, training procedures will still be necessary to cater for new staff and for system amendments. The latter case will depend upon the scale and nature of changes required. The amount of effort required to train new staff will once again depend on the nature and complexity of the user/

61

system interface, but this should flow naturally from the development/implementa­ tion phase of the project, and any computer based subsystems which were used at that time should be maintained for this purpose, as should user manuals.

10.4 Public relations

10.4.1 Many of the potential computer applications identified in an earlier chapter would not interface with the public, and others such as a patient-scheduling system would probably interface indirectly through Commission staff. However, the longer term applications of Automated History Taking and Computer Aided Diagnosis might require patients to use terminal devices. Obviously, the successful implemen­ tation of such systems will occur only if sufficient patients have confidence in them and are willing and able to use them. The computer assisted linkage of medical records is an application which interfaces indirectly with the public and which has received a lot of attention from the Committee. The development of a comprehen­ sive linkage system could depend to a large extent on a favourable shift in public opinion. Appropriate legislation with regard to security and privacy of medical information, the open support of professional groups such as the A.M.A. and the support and assistance of the news media should be sought in an attempt to gain the necessary public approval for these proposals.

10.4.2 Many potential hospital systems would require the support of hospital clinicians. As some systems would have the ability to radically alter current pro­ cedures in the hospitals (Medical Record and Nursing Order systems for example), it may be expected that proposals in these areas would meet with some degree of resistance, and it would seem prudent to attempt to gain support prior to the introduction of such proposals. The linkage of medical records might be the first involvement of private doctors with the Computer Services area of the Commis­ sion. Although their participation in such a scheme would not be essential, their support, in principle at least, could influence public opinion.

10.4.3 The following are among the Public Relations exercises which could be considered in an attempt to gain the support and enthusiasm of medical practi­ tioners:

staging of computer appreciation courses, both general and specific to a par­ ticular functional area or application proposal;

supply of literature describing successful implementations and current develop­ ments of appropriate computer based systems in Australia and overseas;

sponsorship to seminars and conferences on appropriate topics;

sponsorship for visits to appraise appropriate operational systems in Australia or overseas.

10.4.4 Other health professionals and nursing staff in particular would interface with a number of potential computer systems including the important application of Inpatient Management. Once again the support of these groups would be neces­ sary prior to the introduction of these systems. This category of staff have a desire to reduce the amount of paperwork associated with their duties and they may have to be convinced that the adoption of any new system will not increase the clerical

62

content of their work (apart from providing any other benefits), in order to become enthusiastic. Any of the public relations exercises suggested for medical practi­ tioners could also be considered for these people.

10.4.5 As a group, technical staff are perhaps more likely to accept and welcome a computer system into areas of their work, as in some cases a computer can be regarded as just another piece of equipment. Nevertheless they should also attract a certain amount of Public Relations effort.

10.4.6 Administrative systems in the health care field are generally similar to those long established in Government departments and private businesses, and are accepted much more readily than medical systems. In fact, some computer-based administrative systems are already in operation in the A.C.T. hospitals. However,

computer appreciation courses for administrative staff would still seem to offer benefits.

10.4.7 It is to be hoped that support for the introduction of computer-based systems in the health care delivery field in the A.C.T. will develop from this report. Such support could be reinforced by encouraging the Executive of the Commission to participate in some of the higher level Public Relations exercises

which might be undertaken by the Computer Services Group.

10.5 Conclusions

10.5.1 It is felt that the importance of adequate training, with regard to medical systems in particular, cannot be too heavily emphasised. As a first step, a study of the various approaches adopted towards the development of computer-based systems in medical areas both in Australia and overseas would appear to offer

benefits to the Commission. Before initiation and allocation of resources to a pro­ ject, consideration must be given to the extent and type of training resources which will be necessary both from the Computer Services and user viewpoints, for without proper training and user acceptance, the system will be in danger of

failing. The consequences of such failure could reach beyond the wasted effort and loss of confidence in other functional areas. The system would probably interface to some extent with a number of other computer-based systems (developed or planned), and changes would be required in these to the detriment of overall per­

formance and anticipated benefits. It has been stated in an earlier chapter that worthwhile benefits may be expected from the introduction of computer systems into the delivery of health care in the A.C.T. It is felt that public relations will play a big part in the success or failure of many of these potential systems and it

is important that early steps be taken to commence appropriate activities.

63

CHAPTER 11—SUMMARY OF COMMITTEE’S ACTIVITIES

11.1 It will be evident from the body of the Report above that the Committee has considered a very broad range of both computing and health matters. From this consideration have emerged the various recommendations set out at the front of the Report. The Report is specific to the requirements of the Capital Territory Health Commission. Nevertheless, the general considerations could also have value to other people engaged in providing, or considering the use of computing systems in the provision of health care.

Canberra April 1974

64

APPENDIXES TO THE REPORT OF THE COMPUTER SERVICES PLANNING COMMITTEE

APPENDIX 1

COMPUTER SERVICES PLANNING COMMITTEE TERMS OF REFERENCE

To advise the Minister, pending the establishment of the A.C.T. Health Commis­ sion, upon the computing services necessary for the Commission including inter alia:

1 The limited services essential for initial operation of the Commission.

2 The potential areas of need for ADP implementation relative to the delivery of health care in the Hospital and Allied Services fields in the A.C.T.

3 The inter-relations in terms of information flow which should exist between the several components of the health care delivery system and the means by which the servicing of these relationships might be enhanced by appropriate computing techniques.

4 The characteristics of computing systems adequate to the needs specified in 1, 2 and 3 above.

5 Recommended priorities for study, development and implementation of the various phases of the computing systems referred to in 4.

6 The relevance of readily-available systems or special purpose software and the preparation of recommendations for its use as appropriate as a component of the computer systems to be proposed.

7 A broad assessment of the resources required to develop, implement and main­ tain the computing systems proposed in the context of an agreed time-table for progressive implementation of the several components of the system.

8 The acquisition of requisite resources in terms of equipment, technical person­ nel and ancillary support. This advice should encompass any proposals for access to such resources in advance of systems self-sufficiency.

9 Appropriate techniques and resources for training, covering relevant activities of those personnel who will relate to the system.

10 The strategic aspects of systems fall-back arrangements which recognise the special needs of systems availability of the Hospital and Allied Services environ­ ment.

The Committee shall be empowered to seek the assistance of experts to assist it in its deliberations.

The Committee shall also be empowered to create such Working Parties and Groups as it deems appropriate to achieve its objectives.

67

APPENDIX 2

A LIST OF MEETINGS OF THE COMPUTER SERVICES PLANNING COMMITTEE AND ITS WORKING PARTIES

Committee meeting dates and main topics

2 8 /8/73 Chairman’s address on objectives and goals. Consideration of Terms of Reference. Formation of Working Parties 1, 2 and 3.

11/9/73 W .P.l progress report. W.P.2 progress report.

17/10/73 W .P.l report on T.R .l accepted. W.P.2 paper on Medical Record Linkage accepted. Paper on developments in automated health care delivery systems in Australia and overseas. Formation of Working Party 4.

15/11/73 W.P.2 responses to Medical Record Linkage paper. W.P.2 paper on the use of the HASAC patient identification key in the A.C.T. accepted. W.P.2 paper on potential areas of need outside the hospitals accepted. W.P.4 progress report. Paper on developments in automated health care delivery systems in

Australia and overseas accepted. Interim Report of Committee.

13/12/73 W.P.2 paper on possible areas of computer application in A.C.T. hospitals. W.P.4 report on T.R.6 accepted. W.P.4 interim report on T.R.4 accepted. Interim Report of Committee (accepted prior to meeting). Formation of Working Party 5.

2 6 /2 /7 4 W.P.2 paper on possible areas of computer application in A.C.T. hospitals accepted. W.P.2 paper on Information Flows accepted. W.P.4 report on T.R.4 accepted. W.P.5 report on T.R.5 accepted. W.P.3 report on T.R.7 and T.R.8 accepted. Papers on T.R.9 and T.R.10 accepted. Final Report of Committee.

27/3/74 Consideration of draft final report of Committee.

68

APPENDIX 2

Working Party meetings

W .P.l 29 /8 /7 3

6 /9 /7 3 3 /10/73 15/10/73

W.P.2 27 /8 /7 3 5 /9 /7 3 17/9/73 2/1 0 /7 3 11/10/73

2 /11/73 6/12/73

W.P.3 11/2/74 15/2/74

W.P.4 7 /11/73 4 /1 2 /7 3 7 /1 2 /7 3 21/12/73

2 3 /1 /7 4 8 /2 /7 4

W.P.5 1 /2 /7 4

69

APPENDIX 3

COMPOSITION OF WORKING PARTIES TO THE COMPUTER SERVICES PLANNING COMMITTEE

Working Party 1 (T.R.l)

Mr B. McKay (Convenor) Mr R. Gordon Mr J. Shaw Mr R. Wadrop Mr B. Kelly (Secretary)

Working Party 2 (T.R.2 and

Mr B. Miller (Convenor) Dr F. Lomas Mrs A. Kern Dr T. Sale Mr A. Usher Mr R. Wadrop Mr B. Kelly (Secretary)

Working Party 3 (T.R.7 and Mr R. Searle (Convenor) Mr G. Burt Mr J. Shaw Mr R. Wadrop (Secretary)

Working Party 4 (T.R.4 and Mr G. Burt (Convenor) Mr B. Miller Mr J. Shaw Mr A. Usher

Mr R. Wadrop (Secretary)

Working Party 5 (T.R.5) Mr B. Miller (Convenor) Mr W. Bruen Dr F. Lomas Mr A. Usher Mr R. Wadrop (Secretary)

A.C.T. Health Services Woden Valley Hospital Public Service Board Department of Health Woden Valley Hospital

T.R.3)

Department of Health Canberra Hospital A.C.T. Health Services Canberra Hospital

Repatriation Department Department of Health Woden Valley Hospital

T.R.8)

Department of Health Department of Health Public Service Board Department of Health

T.R.6) Department of Health Department of Health Public Service Board Repatriation Department Department of Health

Department of Health A.C.T. Health Services Canberra Hospital Repatriation Department Department of Health

70

APPENDIX 4

VISITS UNDERTAKEN BY THE COMPUTER SERVICES PLANNING COMMITTEE

31/8/73

27/9/73­ 28/9/73

18/12/73

Repatriation Hospital, Concord, Sydney.

Computer Study Group, Monash, Melbourne (Hospitals and Charities Commission, Victoria). The Royal Melbourne Hospital, Melbourne. Alfred Hospital, Melbourne.

Mercy Maternity Hospital, Melbourne. Bates, Smart and McCutcheon, Melbourne (Design Architects for the Belconnen Health Complex).

IBM, Canberra.

The Committee wishes to express its thanks to those people involved in the organ­ isation of the above visits. Thanks are also extended towards staff members of A.C.T. Health Services, Canberra Hospital and Woden Valley Hospital who assisted in the examination of various functional areas within those organisations.

71

APPENDIX 5

MEDICAL RECORD LINKAGE—AN EVOLUTIONARY APPROACH

Contents:

1 Introduction

2 Issues of privacy and community acceptance

3 Patient identification

4 Definition of terminology

5 Decentralised medical record linkage

6 Centralised medical record linkage

7 The integrated patient record data base

8 Conclusions

Figure 1 Conceptual diagram of medical directory Figure 2 Medical directory—record format

Figure 3 Privacy election matrix

Endnote Distribtion of paper and acknowledgement of responses.

1 Introduction

1.1 An examination of the potential application of computers to health care delivery service in the A.C.T. must inevitably involve an exploration of the range of alternatives available to effect varying degrees of medical record linkage. This central theme naturally dilates to the broader issues of privacy, confidentiality and general community acceptance. This paper addresses these problems and suggests

an evolutionary sequence of record linkage procedures which have been grouped under the 3 categories of:

(a) Decentralised Record Linkage

(b) Centralised Record Linkage

(c) The Integrated Patient Record Data Base.

The concept of a Medical Directory which represents the centralised approach has been studied in some depth; not with the motive of presenting a fait accompli to future implementers of health care delivery systems, but rather to explore the significant social, professional and technical ramifications of the proposal.

2 Issues of privacy and community acceptance

2.1 It is perhaps pertinent to firstly identify the benefits latent in an integrated system of patients’ medical data. (In this paper the word ‘medical’ is used in the broader sense, embracing all those activities associated with health care delivery.)

72

APPENDIX 5

The capacity to assemble a patient’s medical history and to make available to his physician a composite picture—or at least the relevant frames—should enhance the quality of the medical service provided and, moreover, these improvements could be directly discernible by the community. Other less tangible, though perhaps no

less salutary, advantages should arise from the use of the data base for epidemio­ logical studies, to facilitate research in both management and clinical fields, to assist in medical education and to provide a management tool in assigning re­ sources, monitoring on-going health programs and planning in the light of trends

in community morbidity.

2.2 Whilst the advantages foreseen above are perhaps not quantifiable in terms of dollars one might suppose that they would have the enthusiastic endorsement of health planners and administrators, of the medical and paramedical professions and presumably of the community at large. However, with all groups there appears

to be widespread apprehension on the question of possible loss of confidentiality of the individual’s medical history, an apprehension which is perhaps being aggra­ vated at present by certain factional interests. Unless or until these suspicions can be allayed by demonstrably adequate safeguards, the effectiveness of an integrated

patient record system could be in considerable jeopardy from public hostility and non-cooperation. It is tempting to highlight all the advantages inherent in such a data base and to discount society’s ‘1984 syndrome’ with reassurances of integrity and security against intrusion, elaborating on the many sophisticated techniques

and devices currently available to maximise security to an unprecedented degree. But is this reassurance really enough? Can the claims of today’s politicians and medical and computer professionals assuage the fear that today’s benevolence might be replaced by oppression and inquisition? And might not the very existence of these information banks serve as a catalyst to such a translation? These ques­

tions lie outside the scope of this paper: suffice to say that the community will only feel secure when these reassurances are reinforced by adequate legislative protection. It is the lack of present legislation and an awareness and concern for community attitudes which suggests an attempt at a phased evolution towards the

fully integrated concept. By constraining the scope of record linkage systems to fall always within the bounds of acceptable public standards one can not only insure, to some extent, against community rejection but also develop a means of demon­ strating the very real benefits inherent in the system. In this way the community

might grow to accept and indeed demand progression to the final phase of a fully integrated patient medical record.

3 Patient identification

3.1 The problem of patient identification lies at the core of medical record link­ age and has received the attention of many expert bodies throughout the world, including the Hospital and Allied Services Advisory Council (HASAC) which has recently made a recommendation on the ‘Feasibility of Uniform Personal Identi­

fication’. To refer to the problem of ‘patient identification’ is perhaps something

73

APPENDIX 5

of a misnomer since the problem is not really one of identifying the patient (who is presumably well able to assist in this process) but rather of identifying the records relating to that person. To this end it would seem appropriate that a uni­ form approach be adopted by all record keeping nodes within the health care network, and further, that the fifteen character key advocated by HASAC be used for this purpose. This key consists of:

(i) the first four characters of the surname,

(ii) the first two characters of the first forename,

(iii) the first character of the second forename,

(iv) sex, (v) day, month and year (excluding century) of birth,

(vi) single digit tie-breaker.

Studies have already demonstrated that the above formula will provide a high level of discrimination and the inclusion of the tie-breaker will serve to differen­ tiate in those rare instances of keys that would otherwise be similar. It should be noted that the tie-breaker which primarily serves the purpose of internal demar­ cation between records (in as much as it is not required to access a record), also preserves compatibility with any national system which might evolve as a result of HASAC’s deliberations.

3.2 In advocating the adoption of the HASAC key it is not necessarily required that this should replace any existing identification systems, such as the hospital Unit Record No., but rather that it should augment any such procedures.

4 Definition of terminology

4.1 Before proceeding further we should define the terminology used in the headings to sections 5, 6 and 7. Decentralised record linkage implies that files of personal and medical information, whether they be manual or computerised are discretely held and remain under the trusteeship of one of the health care nodes. For example, manual records held in a dental clinic or hospital medical records held on the hospital’s computer system would fit this classification. The term decentralised is also extended to include the case where a central index consisting only of the record keys plus pointers to each of the subsidiary files is established but where access to these files can only be made with the authorisation (pre­ defined or otherwise) of the custodian of that file, and the approval of the individual.

4.2 In contrast, the term centralised is used to define what in this paper is termed the Directory approach. In this schema, certain of the information previously held (and possibly replicated) in the subsidiary files is brought forward and stored in a directory which now replaces the previous central index. In common with the decentralised approach this system has no means of automatically accessing the files containing the medical records which remain separately recorded. It is the

74

APPENDIX 5

capacity for directly accessing the clinical information relating to an individual through a single computer system and the amalgamation of this data into a data base which characterises the integrated data base concept.

5 Decentralised Medical Record Linkage

5.1 The decentralised approach is characterised both by its simplicity and by the complete control which each node in the health care delivery system retains over its own manual or computerised records. The freedom remains for various meth­

ods of local indexing, filing and storage of medical records. Thus the systems briefly described in the following paragraphs neither require nor preclude the use of computers at any of the nodes. Accordingly, a hospital may acquire computing facilities and store medical records on computer-readable media without invalidat­

ing the medical record linkage system. The basic requirement is that each node includes the derived key in each record. It should be noted that, whilst this approach presents no privacy overtones which do not already exist and are cur­ rently accepted by the public, it would be wise to anticipate a degree of com­ munity intolerance to the introduction of computer held records.

5.2 In its simplest form the concept varies from the current method of record linkage only insofar as use is made of the derived key to locate required records. Without the need for any central record a health node could enquire of another using the derived key. This system can be easily introduced and offers future compatibility with broader systems.

5.3 The next step could be the establishment and maintenance of a central index, either manually or on a computer. Each record in the index would contain only a derived key plus pointers to the various locations at which it was known that records with a matching key existed. The index would obviously rely on being

informed when a new patient attended each node although some links could be obtained via referrals.

5.4 A further advance could occur by combining the central index with a computer-held local index for each node. A local index could be physically located at the appropriate node if computing facilities were available, or it could be held on central facilities, but regardless of this it would remain under the control of that node.

5.5 A central index record would then point to specific records in various local indices. Each local index record would further point to the actual medical record but in addition it might contain any personal and/or medical information as determined by the controlling authority. While remembering that access to a local

index would be under the control of the relevant node, this linkage system would appear to offer advantages in ease of verification that the record is for the correct patient; the information required might be in the local index record; ease of loca­ tion of the medical record using the pointers from the local index; and possible

future integration of information.

75

APPENDIX 5

6 Centralised record linkage

6.1 This phase of development is characterised by the establishment of what we call a Medical Directory, which is held centrally, is under the custody of the Health Commission and is subscribed to and accessible by any of the participating nodes.

6.2 Essentially the Medical Directory consists of a file of records relating to each person in the community who has at some time or another come into contact with the health care delivery system and who has elected to have his medical history co-ordinated. Each record may be broken down to seven major fields as follows:

(a) Record Key As mentioned earlier the HASAC 15 character derived key is recom­ mended.

(b) Primary Identification Field (PIE) This consists of the patient’s full surname and given names and serves the additional function of providing reassurance that a retrieved record relates to the patient concerned. It is mandatory in the sense that the information must be present in the record. The minimum information necessary therefore to establish or locate a record for a patient is:

Full Name Sex Date of Birth.

The basic kernel of information is not seen as threatening intrustions of privacy and, on the basis of ‘name, rank and serial number’, should be acknowledged by the community as a necessary and inexcessive require­ ment to establish identity.

(c) Privacy Election Matrix (PEM) In accordance with the Government’s policy of requiring individual acquiescence to the linking of medical records, inclusion of privacy safe­ guarding keys within the record are recommended. The exact nature of this locking mechanism need not be examined at this stage but merely to illustrate the concept we may consider the Privacy Election Matrix

(PEM) as depicted in Figure 3.

This matrix defines whether the presence of records in each of the separate repositories should be made known to each of the separate authorised enquirers. It is important to note that we are safeguarding here against

the possibility of gleaning information on the existence of a record not on the contents of a record; it might for example preclude an enquirer at a Dental Clinic from gaining awareness of the existence of psychiatric records. This high level security mechanism will effectively exclude unauthorised access to information from which inferences may be drawn.

76

APPENDIX 5

The right to inspect the contents of a medical record are further safe­ guarded by the custodian of the record retaining responsibility for dis­ seminating any information contained therein.

It is further envisaged that the default configuration of the matrix (i.e. the form that it would take when the patient has made no specific objec­ tions to the availability of data) would be defined by a standard template which, far from providing carte blanche, would prohibit access where

it was neither necessary nor desirable.

The patient’s privacy elections must also be regarded as confidential, again in order to preclude speculative inference, and the system must be so designed that no enquirer can determine either directly or indirectly

that any election has been made. This can be achieved by ensuring that the system responds to a request for information to which the enquirer is not deemed privy in exactly the same manner as it responds to a request for information that does not exist.

(d) Secondary Identification Field (SIF) The SIF carries only two elements of information.

Maiden (or previous) name, Address.

These are to be used where necessary as a means of further substantiating correct identification of the patient, but are nevertheless optional and will only be included with the consent of the patient. It is foreseen that the inclusion of maiden name may be of significant advantage if attempts are

made at family record linkage.

(e) Personal Details Field (PDF) The personal information field as shown in Figure 2 also contains infor­ mation only with the patient’s consent. It has been included mainly with a view to evolution of the system and to obviating the redundancies

associated with replication of this information in each of the satellite medical record files. It is not a pre-requisite to system implementation.

(f) Vital Medical Data Field (VMD) It is envisaged that this field might contain information relating to a patient’s allergies, drug reactions, notification of chronic conditions such as diabetes and perhaps even immunisation history. Again this informa­

tion is optional and will only be included with the consent of the patient but it is assumed that the potentially lifesaving nature of this information would make its inclusion quite acceptable to the individual. It should be emphasised that this field is not intended to carry information that might encourage critical medical action without corroboration of the data. For example the inclusion of blood grouping would seem to be super­

fluous since cross-matching would always be obligatory prior to trans­ fusion.

77

APPENDIX 5

A serious criticism which can be levelled at the inclusion of vital medical data and, to a lesser extent, identification and personal information hinges about determining responsibility for inserting or amending data in these fields. Clearly any change to the VMD can only be made by an appropriate node in the health care delivery network and, ideally, the record might also contain the ‘signature’ of the responsible doctor. Simi­ larly, a patient might wish to use one address for (say) a psychiatric consultation and another at a dental clinic. While these problems would certainly require more detailed consideration in designing the system they do not appear to be insoluble and should not invalidate the practicability of the proposal.

(g) The Medical Episode List (MEL) The MEL is composed of a series of pointer elements each one of which relates to a medical episode and which shows in each case the date, location and local record number associated with the episode. The date would refer to the first consultation in relation to the episode or to the admission date in the case of a hospital episode. The location may be required to be subdivided (e.g. specific doctor within a health clinic or outpatient clinic within a hospital).

Ideally, each element would also include in coded form, where appro­ priate, the primary and subsidiary diagnosis relating to the episode. This data whilst necessarily demanding the acquiescence of the patient in­ creases the usefulness of the directory by an order of magnitude since it now serves as a base for epidemiological studies, for clinical research and for health care planning and monitoring.

6.3 An alternative to the Medical Episode List might be a Location List which would contain elements pointing to the last episode at each of the health care delivery nodes. Whilst this approach offers advantages of economy of space in the record this must be offset by the major disadvantage of incompleteness. Given that the fully integrated patient record system should be event-oriented it would seem more appropriate that the initial system should also assume this characteris­ tic. Furthermore, the inclusion of diagnosis within a location-oriented record would be of extremely questionable use.

6.4 The capture of data to constitute the Medical Episode List could be consid­ ered from two aspects. Firstly, the encounter with an institutional node of the health delivery network, e.g. hospital, clinic, health centre, etc., would be notified to the system directly by that institution. For the non-institutional nodes such as the general practitioner it is less likely that direct notification would, in the short term, prove practicable. However, with the accord of the medical profession, limited information could be gathered when the patient interfaces with an insti­ tutional node by noting also the name/code of the referring doctor.

6.5 The table below indicates very roughly the size of the Medical Directory. The assumption is made that, on average, there will be three elements in the MEL.

78

APPENDIX 5

Field No. of characters

Key 15

PIF 40

PEM 40

SIF 60

PDF 150

VMD 50

MEL 105 (3 x 35)

460

6.6 Assuming a population of 200,000 this would indicate a file size of approxi­ mately 92,000,000 characters. Such a file can be considered medium size, and even if supported by a data base management system with consequential overheads, would still be entirely reasonable, ft should also be appreciated that a recorded population of 200,000 is a highly inflated figure and it is not likely that this volume will be encompassed for some considerable time. A more reasonable starting size for the file might therefore be considered as 30 to 40 million characters.

6.7 Turning now to the operational characteristics of such a system one is faced with the immediate dilemma of whether, at inception, the system should be batch- oriented or should be conceived with on-line, real-time characteristics. Undoubt­ edly the final objective of an integrated data base would lend itself to real-time

manipulation and interrogation through terminals strategically placed in the health network. Through these terminals the data base would be accessible to medical and authorised para-medical and clerical staff who, after identifying themselves to the system using either a password or perhaps by medium of a badge reader,

could retrieve and/or update the file to the extent of their own delegation and the privacy elections of the individual patient.

6.8 One might consider operating such a directory in a batch-oriented environ­ ment whereby the directory would be updated perhaps daily and complete listings distributed periodically to each interested node using microfilm or microfiche where justified. However, such a proposition, whilst undoubtedly possessing the

inviting attributes of conceptual simplicity and economy of installation, raises serious doubts when one contemplates the cumbersome and unresponsive means of interfacing with the system. The use of the HASAC key as the sole means of addressing a record could, in a batch environment lacking any solid editing cap­

ability, readily lead to a chaotic situation where episodes are credited to the wrong patient or lost entirely through an error in the key causing a new record to be created. In an on-line environment, on the other hand, one can contemplate a dialogue between computer and operator which, by presenting additional identify­

ing information would permit corroboration that the correct record had been selected.

79

APPENDIX 5

7 The integrated patient record data base

7.1 This concept follows on from the Centralised approach by permitting the Directory not only to point to computer held records but also using it as the central mechanism by which these records may be retrieved. It is not the intent of this paper to address itself in any depth to this concept which is rather seen as the culmination of an evolutionary process. Undoubtedly this development will pose the greatest technical challenge and raise profound ethical, legal and social problems. Problems of accessibility (who will be able to discover that the euphe­ mistic diagnosis on Joe Blow’s leave certificate hides a disorder which might place his present job in jeopardy?); problems of extrapolation (will the data be co­ ordinated with other unrelated files so that an individual’s socio-medico-economic

history is laid bare?); problems surrounding the right to inspect and correct (can the individual have access to his own record to ensure its veracity?)—all these, and many others, are areas which must receive social and legislative attention and the solutions to which, if and when forthcoming, will radically influence the strat­ egy, design and implementation of such an ambitious system. It is unrealistic to expect professionals of any single discipline, whether it be medical or computer, to take the field in these delicate precincts until a national consortium of expert opinion has defined at least some of the rules of the game. However, the basic Medical Directory should provide a powerful and flexible foundation upon which to develop towards this final phase.

8 Conclusions

8.1 The collection of schemata for medical record linkage outlined in this paper does not purport to be exhaustive. Similarly, the selection of the broad classifica­ tions of decentralised, centralised and integrated is to some extent an arbitrary one and the existence of a degree of overlap is accepted. Nevertheless the broad groupings employed and the specific approaches that are presented do serve to

highlight the evolutionary nature of a phased approach towards the final objective of a fully-integrated patient record data base.

8.2 It is not possible, at this time, to recommend which of the range of alterna­ tives presented would prove to be the most appropriate starting point for imple­ menting a system of medical record linkage in the A.C.T. It is considered that the introduction of legislation regarding confidentiality with respect to computer held information, together with the shifting mood of public opinion would overwhelm­ ingly influence the strategy to be adopted. To reach a conclusion on this matter would require a great deal more study and canvassing of professional and lay opinion and might, even then, be subject to revision in the passage of time leading up to system implementation.

8.3 In summary, the phased approach outlined in this paper would appear to offer several advantages:

(1) Issues of privacy and confidentiality are effectively controlled by safety features which are at least as stringent as those presently in existence.

80

APPENDIX 5

(2) It allows phased implementation to computer-held records of any sub­ system within the health care delivery network.

(3) It retains the option to develop by means of satellite computer systems rather than integrating all records within a central data base.

(4) Where necessary administrative autonomy over medical records may be retained within the Health Centre.

(5) It permits patients’ records which are necessarily not amenable to com­ puter storage (i.e. free text records, subjective assessments, graphical records such as X-rays, etc.) to remain outside the system but still be known to the system.

(6) In acknowledging and utilising the HASAC recommendations for patient identification the system anticipates from the outset the possibility of extension or inclusion within a broader regional or even national system of linked medical records.

81

APPENDIX 5 Figure 1 Conceptual diagram of Medical Directory

The Medical Directory ‘points’ to the patient’s records by indicating their locations and the locally known retrieval references.

Card: EAR - 14

Dental Clinic Card File

Hospital and Laboratory Records

Record: ROGEERAM 210331

Social Workers’ Records

M.D. Patient: ROGERS, ERIC ALBERT MALE born: 21 MARCH 1931

Physician’s Records

Name: E. A. Rogers

Medical Records

82

Figure 2 Medical Directory APPENDIX 5

Record Key

Tie-breaker

Primary Identification Field Surname Forenames Sex

Date of birth l ExPlicit in keV

Privacy Election Matrix

Secondary Identification Field Maiden (or previous) name Address

Personal Details Field Marital status Occupation Name and address—next of kin Nationality

Religion Pension details Health insurance details, etc.

Vital Medical Data Allergies Drug reactions Chronic conditions

Immunisation history, etc.

> 1

■a e a s

s e o '£ o

tr u ZJ Ό

S w

■5 s

83

APPENDIX 5

Figure 3 Privacy Election Matrix

s *5 cr

Custodian of Record ti P-" d Hospital

Health clinic ‘A’

Health clinic ‘B’

Dental

Social workers

Psychiatry

Laboratory (Haematology)

Laboratory (Bacteriology)

Laboratory (Histology)

Laboratory (Cytology)

Radiology

G.P.s records y y y y y y y y y y y y

Hospital records y y y y y y y y y y y y

Health clinic ‘A ’ X X y X X X X X X X X X

Health clinic ‘B’ y y y y y y y y y y y y

Dental y y y y y y y y y y y y

Social workers y X X X X y y X X X X X

Psychiatry y X X X X X y X x X X X

Laboratory (Haematology) y y y y y y y y y y y y

Laboratory (Bacteriology) y y y y y y y y y y y y

Laboratory (Histology) y y y y y y y y y y y y

Laboratory (Cytology) y y y y y y y y y y y y

Radiology y y y y y y y y y y y y

84

APPENDIX 5

Endnote

In view of the ‘planning’ nature of this report and the controversial matters it addresses, Committee decided to seek further informed reaction by circulating copies to selected personnel within those organisations represented by Committee. All distributed papers were marked ‘In Confidence’. Committee wishes to record its thanks to all who ten­

dered advice and comment on the paper.

The circulation list was as follows:

Dr Cowan Medical Advisory Council

Dr Purchas Medical Advisory Council

Dr Burge Medical Advisory Council

Dr Connors Medical Advisory Council

D r Davies Medical Advisory Council

Dr Heap Medical Advisory Council

D r Hurley Chairman, Dept, of Medicine, Canberra Hospital

Dr Goulston Dept, of Medicine, C.H.

Dr Hehir Chairman, Dept, of Obstetrics, C.H.

Dr Atkinson Chairman, Dept, of General Practice, C.H.

D r Pearson Chairman, Dept, of Surgery, C.H.

Dr Wallner Chairman, Dept, of Anaesthetics, C.H.

Miss James Director of Nursing, C.H.

D r Corry Specialist in Charge, Rehabilitation and Geriatrics, C.H.

Miss Pocknall Medical Record Librarian, C.H. Dr McGarn Clinical Superintendent, C.H.

Dr Ireland Assistant Clinical Superintendent, C.H.

Dr Utley Director of Radiology, C.H.

Prof. Whyte Clinical Science Unit

D r Cochran Melba Health Centre

Dr Caine Scullin Health Centre

Mrs Seddon Narrabundah Health Centre

D r Tennant Acting Director, Psychiatric Services

D r Walshe Acting Director, A.C.T. Health Services

D r Pang General Practitioner

D r Dixon Medical Officer, Child Health

Mr Kettle Chief Dental Officer

M rs McLennan Exec. Officer, Nursing Section Dr Lawrence Psychiatrist, Woden Valley Hospital Miss Prefontaine Medical Record Librarian, W.V.H. Mrs Montgomerie Chief Social Worker, W.V.H.

Miss Lenne Acting Director of Nursing, W.V.H.

M r Davis Chief Pharmacist, W.V.H.

M r Gibb Chief Radiographer, W.V.H.

Miss Adams Chief Physiotherapist, W.V.H. D r de Souza F.A.D.G., Department of Health

Dr Edmonson F.A.D.G., Department of Health D r Langsford F.A.D.G., Department of Health

M r Carroll F.A.D.G., Department of Health

M r Dunlop F.A.D.G., Department of Health

M r West A.D.G., Department of Health

M r Finlay A.D.G., Department of Health

85

APPENDIX 6

HASAC PERSONAL IDENTIFICATION K E Y - ELECTORAL ROLL ANALYSIS

1 During discussions on medical record linkage the Committee was informed that the A.C.T. Electoral Roll contained the information necessary to derive the patient identification key recommended by HASAC (viz. Full Name; Sex; Date of Birth). It was decided that an exercise should be undertaken, with respect to the

adult population contained on the Electoral Roll, to evaluate the usefulness of this key in the A.C.T.

2 Accordingly a magnetic tape file containing a copy of the Roll was obtained from the Electoral Office and converted to a form suitable for input to an analysis program which had been prepared by the Repatriation Department for a similar exercise at an earlier time. This program derived the HASAC key for each person on the roll and reported whenever duplicate keys were found. The HASAC key is:

First four characters of surname, First two characters of 1st forename, First character of 2nd forename, Sex (M or F), Date of birth in form DDMMYY, and Single digit tie-breaker.

A summary from the results of this work is as follows:

Number of persons on the roll = 90,818 Sex distribution: Male — 45,876

Female = 44,940

Unknown = 2

Number of duplicate keys = 76

3 The records which produced the duplicate keys were investigated with the assistance of the Returning Officer for the A.C.T. Electoral Office, and four categories were established.

(a) Duplicate entries on the Electoral Roll = 29

These were cases where it was obvious that the two records concerned were for the same person.

(b) Apparent duplicate entries on the Electoral Roll = 4 1

In these cases, an electoral card could be found for only one of the two entries concerned, and it appeared likely that the two entries were for the one person.

(c) Different people, with one entry having the wrong date of birth in the magnetic tape record = 5

(d) Twins (one set) = 1

76

86

APPENDIX 6

4 The apparent duplicate entries on the Roll could not be confirmed as such without further detailed investigation, but it would appear that the twins men­ tioned in (d) above provided the only legitimate case of duplicate keys.

5 A second run was made, for interest only, omitting the 2nd character of the 1st Forename and thus producing a 13 character key. This resulted in two extra duplications but they both fell into the ‘apparent duplicate entry’ category.

6 Committee wishes to express its gratitude to the A.C.T. Electoral Office for the assistance received in this exercise.

87

APPENDIX 7

REVIEW OF POSSIBLE AREAS OF COMPUTER APPLICATION WITHIN THE A.C.T. HEALTH CARE ENVIRONMENT

Introduction

1 This Appendix sets out to identify the many possible areas of application of computers to the processing of both clinical and administrative information within the A.C.T. health care environment and to comment briefly on the functional characteristics of each application.

2 The objective of this report has been to compile a reasonably exhaustive pic­ ture of information processing possibilities based both on overseas achievements and needs peculiar to the Canberra environment. Although certain areas will clearly be accorded little if any attention within the scale of priorities to be established, they have nevertheless been included for the purpose of completeness. This Appen­ dix does not attempt to attach priorities to the various areas which are listed in alphabetical sequence as follows:

Application area Appendix page no.

1 Ad hoc research projects 91

2 Ambulance services 91

3 Analysis of ECG recordings 91

4 Automated history taking 92

5 Blood Bank 94

6 Child health 94

7 Clinical laboratories 94

8 Clinical service departments 96

9 Commercial systems 97

10 Computer-aided diagnosis 99

11 District nursing 99

12 Food services 99

13 General communications 101

14 Health care activity analysis 103

15 Health centres 104

16 Inpatient management 104

17 Intensive care monitoring 107

18 Library services 107

19 Medical records 108

20 Mental health services 112

21 Nurse rostering 112

22 Nursing homes 113

23 Nursing orders 113

24 Office services 115

25 Operational research and Ο & M 115

26 Patient billing 116

88

APPENDIX 7

27 Patient scheduling 116

28 Pharmacy 118

29 Physiological monitoring/measurement 121

30 Preadmissions 122

31 Preventive health 124

32 Private health facilities 125

33 Registration boards 126

34 Supply 126

35 Surgery 127

36 Systems training 128

1 Ad hoc research projects

1.1 This is an area in which a need for computing assistance has been evident for some while. The Research and Planning section of A.C.T. Health Services is responsible for the monitoring and evaluation of health services and the planning and development of new facilities and services in the A.C.T. Each project would

require a separate study to determine its particular need for assistance but, in general, computers could be useful in the construction and manipulation of models and the tabulation and application of statistical analysis techniques to data ob­ tained from surveys. Generalised statistical packages could be very useful in this

area.

2 Ambulance services

2.1 Ambulance services in some parts of Victoria and New South Wales use a computer system to perform the following functions:

Maintain subscribers file Produce renewal notices Maintain debtors’ ledger and issue accounts to non-subscribers Produce operating statistics.

2.2 The introduction of a similar system into the A.C.T. will possibly depend on future decisions with regard to charges. If charges are increased and a subscription scheme started, such a system would probably be of benefit. On the other hand, if charges are eliminated, the need for computing assistance will diminish.

3 Analysis of electrocardiogram recordings

3.1 G e n e r a l

3.1.1 The application of computers to the measurement and analysis of ECG patterns has attracted the interest and attention of a number of cardiologists throughout the world. A range of programs have been developed which will ana­ lyse in a most sophisticated way the digitised output traces from ECG measuring

devices in order to arrive at highly accurate interpretations to assist the clinician in the diagnosis of cardiovascular problems. In a similar manner analogue and hybrid devices are being used in on-line monitoring of the seriously ill patient for

89

APPENDIX 7

the detection of arrhythmias and other irregularities although such systems would appear to fall more properly within the area of patient monitoring.

3.1.2 In a typical ECG interpretation system one might find an analogue to digital converter attached to the recording device and the digitised equivalents of the trace recordings either recorded temporarily on magnetic tape for subsequent processing or transmitted via acoustic couplers and telephone lines to the com­ puter. Using pattern recognition and sophisticated analytical techniques the com­ puter can then rapidly produce detailed interpretive reports and by drawing on an

extensive vocabulary of phrases can produce diagnoses in free text. Standard reports may be produced for the patient’s chart and data may be stored for later comparative interpretation. In addition the interpretations derived may be accom­ panied by detailed reasons so that the system assumes the additional role of being an instructional tool.

3.1.3 Users of these systems claim a dramatic reduction in interpretation time on the part of the cardiologist and place great emphasis on the ability to provide a rapid, economic and highly reliable means of obtaining expert ECG interpreta­ tions. With the increasing emphasis, particularly in the United States, towards preventive medicine and the trend towards health screening centres, the use of automated ECG interpretations as a routine test is becoming commonplace. In the Canberra scene where such trends are less apparent one can nonetheless envisage the application of such techniques both within the hospital environment and per­ haps also health centres.

Possible areas of use:

Hospital inpatients Health centres.

Possible applications:

Preparation of standard interpretative/diagnostic reports. Storage of cumulative results for comparative interpretation. Servicing of remote ECG units via telephone lines. Incorporation of results within a computer-held patient record. Use of computer-prepared interpretations as an instructional tool.

4 Automated history taking

4.1 General

4.1.1 A significant amount of effort has been devoted to the development of programs which will, to varying extents, relieve the clinician of the time consuming interrogative role which inevitably precedes any diagnostic process. By presenting the patient with a carefully and logically structured questionnaire the system may respond to his replies to each yes/no or multiple choice question, using branching techniques, in such a way that the ‘conversation’ focusses attention on his par­ ticular complaint(s). Such a dialogue might be conducted using visual display

90

APPENDIX 7

terminals or cards which can be optically scanned and even supported by graphic displays and audio systems.

4.1.2 On conclusion of the examination the system may produce for the physician a formatted summary report either outlining all the patient’s responses or produc­ ing an exception type report which present only those areas which have evoked a positive response. This report would then form the basis upon which the tradi­

tional doctor/patient dialogue may be used to augment any pertinent line of questioning.

4.1.3 The techniques of automated history-taking would not appear, in the A.C.T., to have particular relevance to the hospital inpatient environment where the patient’s history and the preliminary diagnosis is usually known to the referring doctor. However, for emergency admissions and outpatient clinics the concept

appears to have some application and could also be extended to service Psychiatric Services, Health Centres and even G.P.s. In health centres where a patient might be seen by a number of doctors at different times these techniques also permit a degree of standardisation which might otherwise be absent.

4.1.4 In multiphasic screening areas attempts have been made to incorporate the history-taking with the measurement of physical and clinical parameters of the patient (e.g. audiometry, clinical laboratory results, ECG, spirometry, b.p., differ­ ential blood cell counts, urinalysis, etc.) so that a composite picture of the patient

can be presented to the physician.

4.1.5 A consideration of the introduction of automated history-taking techniques must involve a close study of their impact on and acceptability by the patient— there are still differences of opinion regarding the pros and cons of extracting medical history summaries in such a depersonalised manner. Further, it would

appear most desirable to consider using generalised packages which allow the questionnaire to be changed to meet the requirements of the particular examining discipline and to possess multilingual equivalents to service the migrant population.

Possible areas of use:

Hospital inpatients. Hospital outpatient clinics (physiotherapy, diabetic, VD, etc.). Health centres. Psychiatric Services/social workers.

Doctors’ surgeries. Any intended multiphasic screening centre.

Possible applications: Preparation of summary reports to examining physician. Incorporation with physiological monitoring results to produce a more detailed patient summary.

Incorporation with hospital admission procedure. Use as a data base for statistical analysis, epidemiology, research, etc. Use in relation to computer-assisted diagnosis.

91

APPENDIX 7

5 Blood Bank

5.1 The Blood Bank in the A.C.T. is run by the Red Cross Society but it oper­ ates from within the hospitals and uses the Health Laboratories for all pathology work associated with its function. This close relationship is expected to continue following formation of the Commission and consideration could be given to pro­ viding computing assistance in the maintenance of donor files and donor recall procedures.

6 Child Health

6.1 This branch of A.C.T. Health Services includes the following functions: Mothercraft Child immunisation School medical service and School dental service.

6.2 The branch has a serious record storage and retrieval problem and the main­ tenance of these records on magnetic media with linkage to other areas of health care delivery would appear to be the main potential computer application.

7 Clinical laboratories

7.1 General

7.1.1 Clinical laboratories have traditionally formed part of an acute hospital but the Health Laboratory is organised independently of the A.C.T. hospitals and handles requests from all sources, including private medical practitioners. Never­ theless, the laboratory operates from within the hospitals, having staff and facilities at both Canberra and Woden Valley. Centralisation of the Laboratory has been planned for some time and it is expected that this planning will reach fruition

under the Commission.

7.1.2 Computers have been used successfully in clinical laboratories for a number of years now, and the range of hardware/software packages available is quite large when compared with other areas of medical computing. Partly as a result, this tends to be one of the first departments examined when a hospital moves into medical computing. Also, initial automation in the laboratory can, to some

extent, be independent, in terms of both hardware and software, of the mainstream of medical computing design in the hospital.

7.1.3 Laboratory automation falls into two main categories. The first is the control and processing of output from automated laboratory equipment. Small dedicated computers have proved to be appropriate in this role in many hospitals in Australia and overseas. The second category is the automation of clerical duties associated with laboratory work. This part of the system is normally implemented on a larger, general purpose computer, and in some hospitals has been interfaced with other medical computing systems (via the patient medical record in particu­ lar). The dedicated computer may be linked directly to the larger computer as in

92

APPENDIX 7

an on-line system or it can produce results on an intermediate medium such as punched cards or paper tape. Among the clerical functions which can be auto­ mated are the acceptance of test requests, the preparation of collection lists and worksheets, the calculation of results, the issue of interim and cumulative reports, and the production of statistical reports on the laboratory workload.

7.1.4 The A.C.T. Health Laboratory currently performs an average of 30,000 biochemistry tests per month with slightly fewer haematology and serology tests. At present, approximately 85% of biochemistry and 80% of haematology tests are carried out on automatic equipment. The tests performed in other sections of the laboratory such as bacteriology, histology, etc., are all performed manually

and the final results are written descriptions. A similar position in other labora­ tories has resulted in the biochemistry and haematology sections normally being the first to receive computing assistance. Problems being experienced in labora­ tories throughout the world result in part from a shortage in technical staff, a dramatic rise in the number of biochemical measurements and procedures in rou­

tine diagnostic investigations and the introduction of new drugs requiring analytic control.

7.1.5 The following is a list of benefits which have been found to accrue from the introduction of computing into the laboratory, although not all the benefits can be expected in every system.

1 Laboratory procedure is subjected to a searching review. 2 Clerical work performed by technicians is substantially reduced. 3 Laboratory error rate diminishes. 4 Results of tests are available more rapidly.

5 Better presentation of reports is achieved. 6 Interpretation of results can be refined. 7 Laboratory quality control is enhanced. 8 Storage space for laboratory records is reduced.

Possible areas of use:

Clinical Laboratories

Possible applications:

Monitoring automatic analysis equipment. Acceptance of test requests and checking for possible duplication. Preparation of specimen collection schedules and labels. Preparation of laboratory worklists.

Performance of calculations on results after checking for consistency and reasonableness. Preparation of test reports, both interim and cumulative. Updating of the patient medical record, following verification of results.

Preparation of quality control test reports. Preparation of statistical reports on laboratory workflow, etc.

93

APPENDIX 7

8 Clinical service departments

8.1 General

8.1.1 A number of hospital departments have been grouped together under this heading mainly since they share similar characteristics inasmuch as they:

(a) handle both inpatients and outpatients, and (b) maintain their own patient records (at least for outpatients).

8.1.2 The group of departments/clinics which are considered in this section include:

Radiology Nuclear medicine Physiotherapy Psychiatry Social workers Staff clinic Dental clinic Fracture clinic Diabetic clinic

8.1.3 The potential application of the computer to scheduling both inpatients and outpatients through the various services mentioned above is referred to in a separate section of this Appendix and will not be reiterated here. However, the associated problem of compiling and maintaining clinical records deserves attention.

8.1.4 In considering the application of automated record keeping and reporting procedures, a decision must be reached as to whether these records should be kept in free text form (with consequent impairment of the retrieval potentialities) or whether methods of diagnostic/observational coding have been or could be devel­ oped to compact and rationalise these records. Whereas dental clinic records might well lend themselves to a form of coding, other areas such as psychiatry and social work which involve a higher degree of subjective assessment and draw from a broader repertoire of terms might well be restricted, at this stage, to recording observations in free text. In nuclear medicine, unlike psychiatry, work is well advanced in constructing a dictionary of terms and it is estimated that diagnostic statements could be enciphered by selecting from only about 100 different coded words and phrases.

8.1.5 A further matter that requires close attention involves strategic design with respect to the basic format of the patient record—whether a single all-embracing record will cover all aspects of patient servicing or whether individual records

should be kept relating to each of the service departments. The use of a data base management system would appear to offer the best of both worlds since the record can be viewed in a variety of logical ways according to the requirements of the user. A radiologist for example might only require access to previous x-ray diagnoses for comparative assessment and in this application the logical data

94

APPENDIX 7

base might not need to incorporate other patient data. Furthermore, varying levels of privacy protection could be placed on different types of records or on different segments of a record so that, for example, staff records could be accessible only to certain authorised enquirers.

8.1.6 Each of the service departments referred to earlier might also utilise com­ puter facilities to monitor stock levels for imprest stores systems and, in the case of radiology and nuclear medicine, to keep control of dated stock such as photo­

graphic film and short-lived radio isotopes.

8.1.7 In the nuclear medicine department a number of esoteric applications relating to the quantification and analysis of laboratory data present themselves. Computers may also be applied to gamma camera examinations to assist in data acquisition, smoothing, quality control and anlysis in relation to dynamic studies.

Canberra Hospital is currently considering the purchase of mini-computer facili­ ties to undertake some of this work.

Possible areas of use:

Hospital service departments and clinics.

Possible applications:

Patient scheduling. Maintenance of patient records. Reporting back to ward level on the results of diagnostic tests ordered for inpatients.

Reporting back to referring doctor in the case of diagnostic procedures on outpatients. Stock imprest control.

Recall procedures. Recall systems have particular relevance to diagnostic departments where certain ‘at risk’ patients should return periodically for further examination. A computer system could assist by issuing recall reminders either directly to the

patient or through his G.P.

9 Commercial systems

9.1 General 9.1.1 This heading is designed to cover those functions which are not peculiar to the health care environment and which may be found in most commercial organ­ isations. They are:

Personnel/Payroll General Ledger Accounts receivable Accounts payable Assets register/Preventative maintenance

Inventory control Budgetary control.

95

APPENDIX 7

9.1.2 These are often the first areas in a hospital to receive ADP assistance because many systems, similar to those required, are already in operation in other organisations. In addition it is now generally accepted that management knowledge and control should improve while, at the same time, cost benefits should accrue with such assistance. Introduction of these systems is comparatively easy because they do not affect medical or nursing staff. However, the implementation of com­ mercial systems may provide this section of the staff with some measure of familiarity with computing systems and assist in easing ADP into medical areas.

9.1.3 In the A.C.T., Woden Valley Hospital is currently using the systems and facilities of the Victorian Computer Study Group in the areas of Personnel/Payroll, Creditors/General Ledger and Assets Register/Preventative Maintenance. Canberra Hospital is either evaluating these same systems, or, in the case of Personnel/ Payroll, has commenced implementation.

Possible areas of use:

Hospitals Health Commission Administration Central Hospital Services.

Possible applications:

1 Personnel/Payroll

2 General Ledger/ Accounts Payable

3 Accounts Receivable

4 Assets Register/ Preventative Maintenance 5 Inventory Control

Maintain personnel/pay records. Maintain establishment register. Maintain leave records. Calculate and record payroll, tax, deductions. Provide employment statistics and budget analysis

reports. Provide account analysis reports. Prepare cheques and remittance advice slips. Prepare trial balance. Provide purchase analysis, departmental costing and budget comparison reports.

(See Section on Patient Billing: this function may virtually disappear.) Produce account statements and status reports. Produce department income summaries and income comparison reports. Maintain an Assets Register, including location details and maintenance record. Produce maintenance schedules and job sheets. Maintain Inventory Register. Record inventory movements and produce purchase orders. Handle receipt verification and back-order procedures. Produce summary reports for management control.

96

APPENDIX 7

6 Budgetary Control Production of appropriate reports in any of the above applications.

10 Computer-aided diagnosis

10.1 The field of computer-aided diagnosis appears to have barely reached adolescence and little can be found in the literature to indicate that substantial success has been achieved in implementing such systems in a production environ­ ment. Discussion still seems to centre about such questions as whether it is more fruitful to tackle the conceptual problem by analysing the decision making pro­ cess or to attempt more pragmatic solutions by studying the physician in his role

as a decision maker.

10.2 It has been said that there are three phases to the diagnostic process: firstly, the ‘correct diagnosis’ is considered as one of a list of possibilities, secondly, it is considered to be the most likely, and thirdly a degree of certainty is reached which allows a decision to be reached in respect of treatment. It is the third phase which

presents the most difficulties—especially when the method of treatment selected has a significant risk factor. This probablistic nature of the decision making pro­ cess has had a major influence on work toward computer-aided diagnosis which appears to be concentrating on a symbiotic approach whereby clinician and com­

puter combine to reduce the uncertainty of the diagnosis.

10.3 Whilst the subject of computer assisted clinical decision making might be an extremely fertile ground for research, it would appear that many technical, professional and ethical problems must be resolved before it can be seriously con­ sidered as a viable supporting mechanism in a health care delivery system.

11 District nursing

11.1 This section of A.C.T. Health Services provides domiciliary nursing for convalescents, the aged and for people who would otherwise require hospitalisation. Computer assistance would be of value in the maintenance of individual patient records, whether local or centralised, and, in a similar role to a hospital’s

admission/discharge system, provide reports on patient demography, scheduling, patient disease distribution and patient origin.

12 Food services

12.1 General

12.1.1 The introduction of computer systems within the area of food services management appears to be fairly widespread in the United States although there is little evidence that the topic is receiving an equivalent level of attention in the U.IC. This is perhaps surprising since the area is one which lends itself, at least in part, to a tangible cost/benefit analysis. Such an analysis would, however, appear to be an after-the-event study since it is not clear how the potential food cost savings of an automated system can be accurately assessed against existing manual

planning procedures without at least a pilot study. Nonetheless, in considering raw

97

APPENDIX 7

food costs alone, which represent a significant item of expenditure on a hospital budget, claims of up to 24% savings, consequent upon the introduction of com­ puter systems, are not uncommon. In addition many U.S. hospitals claim simul­ taneous improvements in staff and resource utilisation and enhanced patient care and satisfaction arising from the improved quality of food service.

12.1.2 Undoubtedly, the claims made by U.S. users require further examination and placing in the perspective of the Australian scene. For example, a study of available literature does not indicate any correlation between savings and hospital size and one may be tempted to conclude that a high savings figure merely repre­ sents an indictment of the inadequacies of the preceding manual system. However, if any substance can be attached to the quoted figures then food service manage­ ment would appear to be a clear candidate for computer assistance. The subject requires further examination.

12.1.3 In the A.C.T. the two major hospitals at present function autonomously in the area of food services although it is understood that plans to centralise this function at the Grace centre are currently under consideration. Whilst the timing of any proposed changeover to centralised facilities is not known it would appear prudent to consider delaying any implementation of computer support in this area until such a move is made if indeed such a policy decision is forthcoming.

Possible areas of use:

Hospital food service departments. Other volume-feeding institutions, e.g. nursing homes, hostels. Centralised food service facilities if forthcoming.

Possible applications:

(i) Menu Planning Utilisation of linear programming techniques to arrive at optimal plan­ ning of menus in 1 to 3 month cycles. Such techniques might take account of conflicting properties of nutrient value, cost, appearance, palatability, popularity, repeatability, etc.

The system would of course allow the dietitian to override any decision and, on the basis of preliminary estimates on the number of servings of each component of the meal, could make tentative cost estimates. These figures would gain precision as a result of returned menu cards.

(ii) Inventory Control Maintenance of comprehensive inventory information on each item, in­ cluding: stock level

unit of purchase location unit cost

98

APPENDIX 7

weight/unit vendor sources date of last purchase, etc.

Provision of automatic reordering facilities. Analysis of comparative costs. Item usage reports. Automatic price adjustment to reflect seasonal changes. '

(iii) Requirement Planning Calculation of the amount of food items (and associated costs) required to satisfy the cycle menu plan. Production of withdrawal authorisations for pantry use in acquiring the

necessary food items.

(iv) Purchasing Completion of grocery lists showing the amount and cost of each item to be purchased for a given cycle. Production of mailing labels. Maintenance of an order file.

(v) Invoice Processing

(vi) Cost Accounting

(vii) Special Diet Processing ■

The system should respond to special dietary orders input by physicians (e.g. special diets, supplementary nourishment, cancellations, NPO orders, etc.). The system should also be stimulated by ancillary orders to service de­ partments such as radiology, laboratory, pharmacy, etc., which might

require diet holds or modifications.

(viii) Selective Menu Processing Printing of daily menu sheets for distribution to wards. Acceptance of patient-completed menu cards. The use of OCR or mark sensing equipment deserves consideration in this context.

Production of tray assembly instructions. Production of food preparation worksheets.

13 General communications

13.1 Undoubtedly one of the major problems facing any large and complex organisation is accommodating the flow of information between its various sectors. This problem is perhaps amplified in the large hospital environment where the information channels are more profuse and where great importance must be placed

on speed, accuracy and reliability of the communication system.

13.2 Traditional methods of communication all possess shortcomings; telephones require the simultaneous availability of two people and the lack of hard copy may

99

APPENDIX 7

lead to misinterpretations; courier services are wasteful in terms of staffing re­ sources and inappropriate in urgent situations; vacuum tube systems appear to leave much to be desired from a reliability standpoint. In addition medical staff are not noted for their calligraphic flair and in an organisation where much com­ munication is via the written word the dangers of misinterpretation or mistranscrip­ tion are very real.

13.3 The establishment of computer-based communications systems seems to offer many advantages not present in traditional methods; information is delivered legibly and immediately, messages may be recovered, rerouted or redelivered with minimal use of manpower resources and they may be ‘broadcast’ to a number of receiving stations without need to repeat the message. In other sections of this report numerous functional areas have been addressed where data communication support might be considered appropriate. However, in all those applications we have viewed the communication process in conjunction with certain procedural etiquettes, that is, a message input to the system will stimulate activities other than merely the delivery of that message to a nominated destination. In this section we are confining our attention purely to message switching systems which, other than invoking certain message accounting procedures, do nothing other than transfer information between terminals.

13.4 Although the establishment of a stand-alone message switching system would warrant very close cost/benefit scrutiny, any decision to implement on-line real­ time systems referred to elsewhere in this report might reduce the cost of message switching facilities to marginal proportions. The use of proprietary data base management/data communications packages could well provide a basis of support for a generalised communications system and cost justification arguments might then assume much lesser importance.

13.5 One might also envisage two main emphases which could be placed upon the use of message switching facilities. Firstly they might be viewed purely as a means of conveying unstructured (i.e. free text) information from point to point in much the same way as a Telex System. Secondly, they could be used as a vehicle of induction to systems under development and scheduled for early implementation. To take a concrete example, let us consider the introduction of a medication system which supports automatic drug ordering from the ward level. Such a system would probably require the input of formatted messages at a ward terminal and might result in not only the generation of medication orders at the pharmacy but also perhaps checks on dosages and sensitivities, updating of the patient medication profile, variations to inventory levels, etc. A message switching facility could be utilised prior to installation of such a system to permit drug orders to be conveyed

to the pharmacy using predefined formats and would therefore constitute a useful training mechanism whereby user staff could adapt to procedures required by the system under development. More importantly, user acceptance of these procedures could be determined in a working environment and any desirable changes result­ ing from user feedback could be made prior to implementation.

100

14 Health care activity analysis

14.1 General

14.1.1 A number of computer systems in this category have been developed in Australia and overseas, with the general aim of collecting and analysing the infor­ mation contained in medical records, so that it can be used to advantage in the improvement of patient care. However, these have usually been hospital systems, concerned only with inpatients. With the trend towards hospitals handling more

outpatients, day patients, etc., and the move towards decentralised facilities, it would appear that an Activity Analysis System should assume a much broader stance, and process information on all types of patients attending various health care facilities.

14.1.2 An expansion of the objectives of such a system could be made as follows:

To provide indices of diseases and operations,

To monitor public health, (including provision of morbidity and mortality statistics as required by the Bureau of Census and Statistics),

To provide data on the use of medical resources to assist research, planning and management,

To provide bed-day statistics by patient category for the purpose of claiming Government Hospital Benefits, and

To provide a foundation for the measurement of outcome of treatment (Medi­ cal Audit).

14.1.3 In most Australian hospitals, some of the above objectives are met only by tedious manual compilation, which inevitably causes some degree of delay and error. The inability to meet these objectives results in a lack of information for research, planning and management.

14.1.4 In a typical Medical Record System, dealing only with inpatients, infor­ mation is supplied to the system as it becomes available by the Medical Record Librarian, and reports are produced on a regular basis (normally monthly, quar­ terly and yearly). Such systems are basically batch in nature. The information of interest may include, for each patient, personal details (age, sex, weight, etc.), length of stay in hospital, initial and final diagnosis (usually in coded form), and details of any surgery performed and services given. Of all this information, the

discharge diagnosis is usually the most difficult to obtain as doctors are sometimes very slow in producing it, unless the hospital is one which can enforce a policy of final diagnosis being required before discharge.

14.1.5 A comprehensive Health Care Activity Analysis System could be estab­ lished on a stand-alone basis, with data being obtained from various health facilities and hospital departments, possibly channelled through the Medical Re­ cord Library. Alternatively, it could be established in conjunction with other

medical computer systems which maintained an integrated or structured patient

APPENDIX 7

101

APPENDIX 7

record file. In this latter case, depending on the depth of information in the patient records, most, if not all of the necessary information would already be available.

Possible areas of use:

Hospitals Health Centres Mental Health Service Child Health Nursing Homes

Possible applications:

Maintenance of a medical record information file, unless suitable files are already maintained by other medical computer systems.

Production of standard statistical reports and indices on a regular basis. Ad hoc production of special-purpose reports as requirements arise. Creation of files for use in the Medical Audit system.

15 Health Centres

15.1. Health Centres are concerned with comprehensive primary health care. It is planned that they may offer any of the following services, depending on the particular requirements of the region: medical practitioner,

dental, pharmaceutical, psychiatric, paramedical, district nursing, and in some cases, maternal, infant and school health.

15.2 Some of these services are currently operating from a central unit but it is planned to decentralise to health centres.

15.3 The main benefit to be gained from computer support would appear to be in the maintenance of either local records with record linkage, or an integrated central record. Only one record is being held for each patient at a health centre, with one exception, i.e. where fee-for-service doctors have so far retained their own separate files. Other possible applications within the health centres are covered

under various functional headings in this appendix, but include pharmacy and patient scheduling systems.

16 Inpatient management

16.1 General

16.1.1 The heading of Inpatient Management has been chosen in preference to the more usual but restrictive heading of Admission/Discharge, and is used to encompass the following functions.

102

APPENDIX 7

Admissions: Patient identification and interview. Record creation. Bed allocation. Notification to other departments (e.g. ward, laboratory, dietary, food service).

Bed Control: Nursing dependency reporting. Patient location/condition reporting. Predictive discharge reporting. Bed census (reports to various departments, e.g. nursing adminis­ tration, food service, medical records.)

Transfers: Inter-hospital. Intra-hospital. Temporary absence. .

Notification to other departments, such as food services.

Discharges: Final diagnosis—discharge notice. Bed release. Notification to other departments.

16.1.2 The pre-admission function is not included as it is looked on more as a front end extension to an Inpatient Management System, and it is covered in a separate section.

16.1.3 In-patient Management Systems have become a well-used entry point into medical computing in hospitals. The main reason is that a patient record, whether structured or integrated, is central to a large number of medical computing sys­ tems, and the admission function provides a convenient opportunity for its

creation. Personal information on the patient is being recorded or checked at this lime, and creation of a record in a system which interfaces with the patient at a later stage will cause duplication of some of this work. Also, every inpatient passes through the admitting procedure which is not necessarily the case in some other

areas. Finally, such a system fills a demonstrated need for ADP assistance in Inpatient Management as defined above, in a way which need not greatly affect nursing procedures and which has been successfully and beneficially implemented in a large number of hospitals.

16:1.4 It is perhaps worth mentioning that the method of classifying patients is somewhat obscure and will require further clarification if the inpatient manage­ ment system is to provide a useful basis for the derivation of meaningful hospital activity statistics. At present there appear to be four main categories of patient:

1 Inpatients This would include all patients who spend at least one night in the hospital.

2 Day Inpatients Patients who are admitted for minor procedures (e.g. cystoscopy) and might be admitted at 7 a.m. and discharged at 6 p.m. the same day. The

103

APPENDIX 7

N.S.W. hospital determination states that any patient who is ‘changed into sleeping attire and put into bed with the usual bed linen’ will be treated as an inpatient and charged the daily rate. However, since these patients never appear on a midnight bed census and would appear to have a zero day bed occupancy they must be treated separately for the purpose of operating statistics.

3 Outpatients Those patients who utilise casualty/outpatients clinic facilities without occupying a bed.

4 Day Outpatients Such a category might be applicable to patients such as those using re­ habilitation who might spend the whole day in the centre, receive meals and be subject to a separate charging structure. In this case each daily attendance could hardly be regarded as a separate admission.

16.1.5 The matter is further confused by the following types of admission:

1 A possible move towards admitting whole families to the psychiatric ward.

2 The admission of a nursing mother together with her baby.

3 The admission to a paediatric ward of a child accompanied by one or more parents. Facilities are available at Woden Valley Hospital for such accom­ modation and at present parents are charged only for meals.

Possible areas of use:

Hospitals Nursing Homes

Possible applications:

Creation or retrieval and checking of patient record, including assignment of Unit Record Number and HASAC key. Bed allocation/release. Automatic notification of patient movement, admission, transfer or discharge to all ‘need to know’ departments. Creation/update of patient accounting record. Interface with ‘Medical Directory’. Production of discharge notice. Nursing dependency reporting (Nursing Administration).

Patient location/condition reporting (Reception, Chaplain service, Doctors’ lounge, Dietician, Administration). Predictive discharge reporting (Nursing Administration). Bed/Ward census reporting (Nursing Administration, Nursing Stations, Medi­ cal Records, Food Service).

Production of other enquiry/statistical reports as desired by medical, nursing or general adm inistration.

104

APPENDIX 7

17 Intensive care monitoring

17.1 General

17.1.1 The area of patient monitoring is a specialised one and can only receive superficial attention in this report.

17.1.2 However, it is known that a number of manufacturers have developed patient monitoring systems which, utilising transducers to measure physiological signals relating to such parameters as temperature, ECG, various blood pressures, respiratory flow, pressure and partial pressures, etc., can perform a predictive

analysis of the patient’s condition.

17.1.3 Amongst the claims made for these systems are:

1 They improve the quality of medical care available to the critically ill through early recognition of impending complications. Certain life-threaten­ ing situations can be detected 3 to 5 hours before the symptoms are notice­ able in conventional monitoring systems.

2 Previously unrecognised cause and effect relationships which exist among respiratory and cardiac variables may be defined.

3 Physiological effects arising from changes to therapy may be immediately observed.

4 Output from the systems, which may be subjected to further computer analysis, provide a useful tool in clinical research.

17.1.4 These systems are usually designed to simultaneously monitor the condi­ tion of several patients. They are not characterised by cheapness and capital costs of $8,000 to $10,000 per bed would appear to be normal.

17.1.5 In Canberra Hospital the Intensive Care Unit services three categories of patient, namely, general ICU, coronary and dialysis. Neglecting the latter group the unit treats approximately 1,200 patients per annum.

17.1.6 A less ambitious and less costly means of servicing intensive care units by providing on-line facilities for capturing and correlating vital signs data might be considered as an alternative approach. In one sense the type of care given to an ICU patient differs only from that given in an ordinary ward inasmuch as it

is more ‘intense’. That is, the number, variety and frequency of tests and measure­ ments taken and therapeutic services administered far exceeds that of a general ward. Since all these actions must be recorded in the patient’s notes the volume of paper rapidly becomes unmanageable and access to specific items becomes difficult.

17.1.7 It is therefore in this area of data collection and information retrieval that consideration might be given to providing computer assistance using either dedicated facilities or tying in with a centralised service.

18 Library services

18.1 General

105

APPENDIX 7

18.1.1 Increasing use is being made of computers in libraries in Australia and overseas, in attempts to improve and expand services which are time-consuming and therefore costly. A major example is the MEDLARS system which is sup­ ported and used by a large number of countries including Australia. MEDLARS

is a search and retrieval system which is used to locate information from a range of over 2,000 medical journals which are subscribed to by the Australian National Library. It is unlikely that a system with all the features of MEDLARS would have been feasible without computer support. With internal library systems, the size of the library is one of the· main factors which influence decisions on possible computer assistance.

18.1.2 In the A.C.T., small libraries are maintained in each hospital and A.C.T. Health Services. These libraries arrange for the purchase, cataloguing, storage and circulation of books and journals within each organisation. The small size of the libraries would appear to indicate little need for computer assistance at this stage. However, the situation would need review if they are combined into one logical, if not physical unit, under the Commission.

Possible areas of use:

Hospitals Commission administration.

Possible applications:

Ordering and purchasing Catalogue maintenance Circulation and loan control Indexing and current awareness service.

19 Medical records

19.1 General

19.1.1 With the trend towards decentralisation of health care facilities in the A.C.T., the maintenance and linkage of medical records over these facilities is assuming increased importance. In this section, medical records produced from all possible sources are considered and, while individual attention is given to some aspects of hospital records, this should not detract from the importance of records held in other facilities.

19.1.2 The medical record has a number of uses including the following:

Communication between members of a Health Care Team,

Provision of an historical record of the patient’s illness and treatm ent, which may be of im portance during a later period of hospitalisation or medical treat­ ment elsewhere (any such record is of medico-legal significance).

Retrospective and prospective research,

106

APPENDIX 7

Education and review (including Medical Audit),

Production of statistical reports both for medical management and for national studies.

19.1.3 The computerised patient medical record, or to be more precise, some part thereof, is central to many of the possible medical computing systems mentioned in other sections of this Appendix. The way in which this record could be stored, and its contents, have not received any attention, however. The following are three

possible approaches which could be adopted in automating parts of the medical record:

(1) Decentralised: Under this approach a separate medical record might be created for each patient, for each medical computing system. Record linkage between systems could be handled by particular programs or manually, using a

key such as the Unit Record Number. An index could be maintained to point to those parts of the patient record held on paper, film, etc.

(2) Structured: Using a Data Base Management System, a structured patient record could be created, providing ‘automatic’ linkage between the various seg­ ments of the record and pointers to those sections held manually.

(3) Integrated: One central record could be maintained for each patient, providing the storage for all the medical systems and all parts of the medical record except where technical difficulties exist.

19.1.4 Variations of the first two approaches have been used in medical comput­ ing systems developed in Australia and overseas. The integrated approach has also been used, but any success has been confined to the experimental environment, (e.g. Attempts have been made to include medical summaries in computer records

in both structured and unstructured (free text) form, and to retrieve records by their content from structured text. However difficulties such as providing a satis­ factory interface with medical staff, storage requirements, etc., have prevented general use of these systems.)

19.1.5 Conceptually automated medical records can be regarded as active or historical. Admission of a patient will cause activation of his record with de­ activation on discharge. On any later re-admittance or consultation the record again resumes activity.

19.1.6 The traditional Inpatient Medical Record consists of a group of documents including admission and patient consent forms, patient history, nursing, medication and test orders, test reports, vital signs reports, etc. These documents come into existence at various times during the patient’s stay and are accumulated at the

bedside or nursing station, until the patient is discharged or dies. At this time the records are forwarded to the Medical Record Librarian, whose job it is to ensure

107

APPENDIX 7

completeness (including the final diagnosis) and to file the records, normally on the basis of a Unit Record Number which is unique to the patient within the hospital.

19.1.7 Some service departments such as Radiology, Nuclear Medicine, Physio­ therapy, Psychiatry, Social Welfare and Clinics in general, may keep their own records on the patients they deal with. Linkage between the Medical Record Lib­ rary and these departmental patient records can be achieved using the Unit Record Number in some cases, or the patient’s name in others, (e.g. The record for an outpatient treated in a clinic at Woden Valley Hospital does not include a Unit Record Number even though one may already have been allocated at an earlier time.)

19.1.8 While a patient is in hospital, his medical records are under the control of the sister in charge of the ward. Later the Medical Record Librarian has respon­ sibility for their privacy. Under a system where part of the record was on computer- readable media, accessibility to that part could be much easier, depending on the

characteristics of the computer system. With a batch system, all information could still flow through the relevant responsible person. If an on-line enquiry capability existed, security would have to be built into the system by the use of badge read­ ers, privacy codes, terminal restrictions, etc.

19.1.9 In many hospitals, staff medical records are held separately from the rest in an attempt to ensure confidentiality in general and privacy from other staff members in particular. In Woden Valley Hospital, such records are the responsi­ bility of the Senior Sister in charge of the Staff Health Clinic. A continuance of this policy under a system of computerised records would appear to require the existence of a subset of records with additional privacy protection features or even a separate file or group of files for staff medical records.

19.1.10 A structured patient hospital record might contain the first and any of the following segments:

Patient identification segment (including Unit Record No., HASAC Key, per­ sonal details).

Vital medical data (including allergies, drug reactions, etc.).

Inpatient management segment (details for each period of hospitalisation in­ cluding discharge diagnosis).

Medication profile.

Laboratory profile.

Physiotherapy profile and similar segments for other service departments or clinics.

Nursing care plan (for active records only).

Nursing orders and observations (including vital signs reporting).

Billing segment (not normally part of the medical record).

108

APPENDIX 7

19.1.11 The format of some of these segments would be larger for an active record than for an historical record as some information might be of use only while the patient is in hospital, and need not be retained after discharge. It might be desired that medical records be held on the ‘Problem-Oriented Record’ basis,

rather than the departmental/functional type split outlined above. One of the possible benefits to be gained from using a Data Base Management System to create structured records, would be the ability to hold the data physically in either manner and yet have access to the information in both ways, by the specification

of two or more logical files.

19.1.12 The paper entitled ‘Medical Record Linkage—An Evolutionary Ap­ proach’ (Appendix 5), proposed the establishment of a unified system of medical record linkage in the A.C.T., and described various stages possible in such a sys­ tem. Such linkage, in all but the final stage of total record integration, would be

largely independent of the method by which the health facility stored its records. The basic requirement necessary to be part of the system would be the inclusion of the HASAC key in each record and the maintenance of an index, on a com­ puter or manually, linking Unit Record Nos. and the HASAC key. The latter

stages of the ‘Directory’ approach would be enhanced by a degree of automatic linking between the directory and the medical index or records. (Subject to satis­ factory privacy controls.)

19.1.13 A Medical Audit has been defined as a system of continuing education based on the continuous evaluation of the quality of medical care as reflected in medical records. It involves the matching of actual patient care against prevailing standards of practice. Using a comprehensive automated medical record, reports

could be produced summarising the treatment administered to various groups of patients over a given period. (Details of patients on admission or consultation; laboratory tests given; x-rays; other tests; operations; medication, etc.) The medical administration would then be responsible for performing the audit and making decisions about the standards of medical care in consultation with the medical

staff. At least one major system in this area has been in use in the U.S.A. for a number of years. An attempt to introduce this system into a Melbourne hospital in 1967 failed because of its cost and non-acceptance by the medical staff. How­ ever, it is likely that a system tailored for the Australian environment would prove

acceptable and valuable. Such a system could of course be run independently, with preparation of suitable input, but the existence of an automated medical record would reduce operating costs and increase flexibility.

19.1.14 Medical records, either those controlled by the Medical Record Librarian or by the individual service departments, Health clinics, etc., are the source of many statistical reports for the information of management, for researchers and for the Bureau of Census and Statistics. This subject has been covered in another

section, headed Health Care Activity Analysis, where it is pointed out that the automation of medical records can provide assistance in the production of these reports.

109

APPENDIX 7

P o s s i b le a r e a s o f u se :

Hospitals Health Laboratory Health Centres

District Nursing Mental Health Service Child Health Nursing Homes

P o s s ib le a p p lic a tio n s :

Creation and updating of patient medical records on active and history files. Creation and maintenance of various indices relating to the medical records. Use of medical records to create problem-oriented records. Inclusion of structured or free-text medical summaries in automated medical records. Provision of special features to cater for automation of Staff Health Records. Production of summary reports to enable medical audit to be carried out. Production of statistical reports including those suitable for comparing hospi­ tals, medical research and epidemiological studies. The patient medical record would be updated and accessed by a number of medical systems as described in other sections of this report.

20 Mental health services 20.1 The work undertaken by the Mental Health Branch of A.C.T. Health Ser­ vices includes welfare assessment of disabilities, speech therapy, occupational therapy, assistance to mentally handicapped persons, operation of ‘hostels’ for psychiatric patients and assistance over a wide range of emotional problems such as behaviour disorders, drug dependence and alcoholism.

20.2 Record linkage within the Mental Health Branch, and, subject to adequate security and privacy safeguards, with the rest of the Health Care Delivery Service, would appear to be the main area which would benefit from ADP support. At the same time the research unit in Psychiatric Services has made use of ADP in the

past and seems likely to have a requirement for future computing assistance.

21 Nurse rostering

21.1 G e n e r a l

21.1.1 Whilst the area of nurse rostering would appear to be a clear prima facie candidate for computer assistance, inasmuch as the complexities of scheduling and resource allocation lend themselves readily to computer solution, one is nonetheless left with the suspicion that this is an area which should be approached with cau­ tion. Rostering clerks, however dispassionate their approach, tend to be on the

receiving end of numerous brickbats from staff who, for one reason or another, feel that they have been unfairly treated. It is not difficult to imagine the com­ puter becoming the butt of even more vociferous abuse and the consequent possi­

110

APPENDIX 7

bility of alienating that very group of staff whose enthusiasm and involvement will be vital to the successful implementation of other systems. It would therefore seem prudent to restrict attention to programs which merely assist in the rostering pro­ cess which, although complex, has rules which can be defined and programmed, and leave the human relations exercise to nursing administration who might hope­ fully be programmed not to ‘pass the buck’.

21.1.2 Student nurses, on the other hand, as a group more susceptible to disci­ pline and regimentation would appear to be more amenable to computer schedul­ ing. Indeed the problems in this area are very great where students are scheduled

through a three year program covering all .relevant areas of experience in the hospital and extending beyond to district nursing, infant welfare and psychiatric nursing. Changes to the availability of training grounds, student drop-outs, lectur­ ing schedules, etc., which have a dramatic impact on manual scheduling systems

could be accommodated fairly comfortably by computer techniques.

Possible areas of use:

Nursing administration Other areas (such as food services, general maintenance, etc.) where rostering problems exist.

Possible applications:

Student nurse long term scheduling. Nurse rostering. General Staff rostering. Allocation of staff to wards on the basis of existing and projected nursing

dependency figures. Interaction with the personnel system on matters relating to annual leave, special skills, student nurse progress, etc.

22 Nursing Homes

22.1 The first of these, which is due for completion in 1975, will provide nursing care for geriatric patients. The patients will be chronic, long term or mobile but requiring some nursing. It is possible that some of the ADP systems developed for the acute hospitals will be applicable to nursing homes, with or without modi­

fication. In some cases, new systems may be warranted. In any event, the homes will form part of any record linkage or central record scheme.

23 Nursing orders

2 3 .1 General

23.1.1 The choice of heading "Nursing orders’ is perhaps a little ambiguous and, since the manner in which it is being used in this paper embraces a somewhat wider interpretation than normal, it might be useful to define broadly those types of information flow which are being covered. These are:

11 1

APPENDIX 7

(1) The recording of patient data as a result of measurement and observa­ tions made at the patient’s bedside.

(2) The capture, recording and display of ‘orders’ which, in their totality, define the nursing care plan for a particular patient. These orders there­ fore have a number of sources ranging from the attending doctor through post-operative instructions, to nursing staff themselves.

23.1.2 It should be noted that we will not consider here the recording and pro­ cessing of routine patient management information which is normally at present carried out by ward clerks. Such functions as logging of admissions, discharge procedures, bed census, the collection of menu selection forms, etc., are all ad­ dressed in other areas of the report. Similarly, the ordering of service facilities, which are normally carried out by the nurse as a result of the doctor’s written or verbal instructions, are also considered elsewhere. On the other hand where the ordering of a service has, as a by product, an alteration to the patient care plan this latter aspect will be considered under nursing orders. For example, the order­ ing of medication involves not only the supply of drugs but also their administra­ tion; the ordering of a laboratory test may also imply other changes to the care plan such as a diet hold or changes to medical schedules.

23.1.3 Nursing staff have traditionally undertaken a whole range of ‘non­ professional’ activites including clerical, housekeeping, messengerial and catering tasks. However it is now becoming accepted practice to transfer these functions to less qualified staff and the increasing array of titles such as ‘ward clerk’, ‘wards- maid’, ‘ward hostess’, etc., used to describe staff who fulfill a supportive role bears witness to the changing philosophy. The nursing profession itself is constantly promoting the concept that nursing skills are a scarce commodity and that staff should be free to concentrate on providing nursing care. Any move to introduce computer systems which can demonstrably reduce the residual clerical work over­ head which still remains, to a greater or lesser extent, with nursing staff would appear to be in accord with the profession’s aspirations and should therefore meet with support.

P o s s ib le a r e a s o f u s e :

Hospital inpatient wards Nursing homes.

P o s s ib le a p p lic a tio n s :

Collection, assembly and reporting on patient data collected at the bedside. This might include the logging of vital signs data (pulse, B.P., respiratory, etc.), physical measurements, fluid balance, behavioural observations, progress notes, etc. Cumulative histories could be printed daily for use by both the attending physician and nursing staff.

Recording of orders arising either from direct instructions or as supplements to other service requests, e.g.

112

APPENDIX 7

medication orders patient mobility orders observational requirements dietary requirements

physiotherapy pre- or post-operative needs intravenous therapy orders relating to dressings, tubes, etc.

Compilation and presentation of comprehensive nursing care plans. Arising from the various orders relating to each patient the system might prepare ‘ward care worksheets’ on either an individual patient basis or by nursing unit so that the various treatments required are scheduled chronologically. Such

nursing care plans could be updated periodically or whenever a patient’s re­ quirements change and should prove useful in reducing the overheads of infor­ mation exchange normally associated with shift changeover.

Changes to patient’s conditions might be notified by ward staff so that enquiries directed either to reception or at the ward clerk level might be answered by requesting a patient condition and location report.

Unconfirmed procedures reminders might be produced as a by product of a system which allows nursing staff to check off each item on the nursing care plan as it is administered. Such a system could alert nurses to procedures which have been ordered but which do not appear to have been carried out within a certain time.

Automated analysis of patient care plans could also serve as a useful basis for estimating nursing dependency workloads, and assisting in the allocation of rostered staff between wards.

24 Office services

24.1 Office service sections would not appear to be a very fertile area for potential computer support but there are at least two functions which should receive con­ sideration. One is a text handling/word processing system which might prove

feasible for common use by all sections of the Commission. The other is a stores system. The benefit which a stores section obtains from ADP assistance increases with the number of different items stocked. Should the stores function be central­ ised within the Commission, it is possible that computer support could be of benefit in such areas as inventory control and costing, forecasting requirements,

re-ordering and follow up.

25 Operational research and Ο & M

25.1 The use of computer-supported O.R. and Ο & M techniques appears to have particular relevance in planning and reorganisation of health care services. Although no in-depth study has been made of the potential need for such assist­ ance, a number of techniques present themselves as possible supportive tools.

113

APPENDIX 7

Standard statistical packages might be used to advantage in analysing and forecasting trends in community morbidity, patterns of health care usage, etc.

PERT techniques might be applied to co-ordinate and control the development and implementation of major projects.

Linear programming and optimisation techniques have relevance in the area of transport scheduling and could perhaps be used to advantage in planning the operation of any central supplies facility.

Simulation techniques might be applied to modelling the flows of patients and/or information through the various nodes of the health care delivery network and within major institutions such as hospitals in order to assess the impact of changes to the nature and deployment of resources. Such studies might also be conducted to gauge the effect on patient flow, staff commitment and computer response prior to the introduction of any real-time computer systems.

25.2 Some of the techniques outlined above would appear to have particular relevance in the relatively short term when concentrated planning must be directed towards the changing nature of health care delivery in the A.C.T.

26 Patient billing

26.1 General

26.1.1 The area of patient accounting which receives such enthusiastic attention in the American scene is far less pertinent when considering the A.C.T. environ­ ment. In Canberra, the only charges which are posted to the account of an inpatient are:

per diem inclusive rate, radiology charges, _

telephone charges.

26.1.2 Casualty patients and outpatients on the other hand will be billed indi­ vidually by each of the clinics/service departments which they attend—e.g. radio­ logy, dental, physiotherapy, diabetic, etc.—and might also incur additional charges relating to equipment supplied or loaned.

26.1.3 Nonetheless the present policy of levying only notional charges for a very restricted range of services and supplies would not indicate an urgent need for computer support and any move towards abolishing charges altogether would leave only workers’ compensation and third party cases as possible revenue- producing areas.

27 Patient scheduling

27.1 General

27.1.1 An alternative heading for this section could be ‘Resource Scheduling’, as it is concerned with the efficient utilization of manpower and equipment while at

114

APPENDIX 7

the same time providing the best possible service to the patient. The areas under consideration are. Health Centres and the following hospital service departments: Radiology, Nuclear Medicine, Ultrasonic Medicine, etc., ·

Dental Services, Physiotherapy, Social Welfare and Clinics in general (e.g. Fracture, Mental Health, Diabetes).

27.1.2 Operating Theatres which could also have been included in the list, are dealt with in the section on Pre-admissions.

27.1.3 Automated Patient-Scheduling Systems have not received a great deal of attention in most areas of health care to date, at least partly because of other tasks having higher priorities. However, a few overseas hospitals have developed such systems, with the following general aims:

to increase utilization of resources (including doctors, nurses, equipment, buildings), to simplify scheduling and eliminate conflicts, to maintain an even workload throughout the hospital,

to reduce the number of visits and waiting times for patients, to produce timely management information reports.

27.1.4 A Patient-Scheduling System could operate on a batch basis but would appear to offer greater benefits as a real-time system. Flexibility would be required to take into account varied parameters for specific patients such as urgency of appointment, personal situation and schedule, and the condition being treated. The system would have to allow for emergencies and cater for staff differences (e.g.

varying work rates of staff in the same service area).

Possible areas of use:

Hospitals Health Centres.

Possible applications:

Maintain appointment schedules for each service area within the system. Depending on particular parameters, determine optimum appointment times as requested. Print appointment notices.

Produce regular department and patient schedules with appropriate instruc­ tions to all ‘need to know’ areas, such as dietitian or transportation. Display on request appointment lists for a particular patient, doctor or facility, etc.

Provide timely management information reports.

115

APPENDIX 7

28 Pharmacy

28.1 General

28.1.1 The development and implementation of pharmacy-oriented systems ap­ pears to be fairly widespread (particularly within hospitals), and offer benefits in the areas of pharmacy administration, improved patient care and automated drug information services. However, one cannot but suspect that the development of these systems, in the U.S.A. at least, has been largely prompted by the profit motive and by the ability of these programs to interface with patient billing sys­ tems. Since, in the A.C.T., patients are not billed for medications this incentive is not pertinent. However, one must examine the potential benefits offering in areas such as:

reduction in pharmacy clerical time; improved stock control; reduction in nursing time in ordering and recording; improved patient/drug and drug/drug monitoring; automation of patient medication profiles and histories; a responsive drug information service to medical, paramedical and pharmacy staff, etc.

28.1.2 Looking more closely at the characteristics of hospital pharmacy systems in particular it is important to note that the design of any such system will be greatly influenced by the pharmacy’s modus operandi. At present the systems used in the two major Canberra hospitals differ. At Canberra the traditional

method of dispensing directly from a central pharmacy to the ward is still adhered to although there appears to be a move towards the ‘ward pharmacy’ concept that has been introduced at Woden Valley Hospital. This involves a ward imprest stock system where the ward pharmacy services perhaps a hundred beds. The currently in-vogue concept of the ‘clinical pharmacist’ which considers the ward

pharmacist as an integral part of the clinical team—even to the extent of accom­ panying the clinician on his rounds and offering medication advice—might also, if introduced, modify the underlying strategies of system design. Other factors which might have a similar effect would be moves towards generic prescribing and/or towards unit dose dispensing where, at any one time, the patient is supplied with only a single dose of each drug. It would appear most desirable that a uniform approach towards drug dispensing and drug control be adopted by the hospitals before work commences on the development of pharmacy support systems.

28.1.3 In summarising the types of systems which have relevance to the function­ ing of the pharmacy one is presented with a fairly clear split between:

1 Pharmacy Administration 2 Patient Medication 3 Drug control 4 Drug information.

116

APPENDIX 7

28.1.4 A range of applications relating to each of these areas is listed below. It may be seen that a number of these appear to be of a ‘stand-alone’ nature, that is, they do not interface with any other system or subsystem and, as such, might

be candidates for early implementation on the basis of relative priority, available resources and user interest. It is worth mentioning that interviews with pharmacy staff at both Canberra and Woden Valley Hospitals have indicated a high degree of enthusiasm for the introduction of computer-based pharmacy systems.

Possible areas of use:

Hospital pharmacy (interfacing with admissions, ward, ward pharmacy and other service departments). A number of the applications outlined below would also have relevance in the health centre pharmacy environment and might even be extended to service

retail pharmacy outlets.

Possible applications:

(i) Pharmacy administration Stores inventory control systems embracing purchasing stock control, stock taking, budget and finance reports, periodic operating reports. Maintenance of stock lists for ward pharmacy imprests. This could be

extended to cover imprests for the many other centres which receive pharmacy supplies, e.g. radiology, physiotherapy,

dental clinic, operating theatres, blood bank, casualty,

staff clinic, delivery rooms, intensive care, etc. Alerts to low stock levels and initiation of reordering procedures with consideration to optimising the quantities to be ordered in order to maxi­ mise any discounts available.

Control of dated stock. Maintenance of lists of medications ordered but not received. Production of statistics on drug usage and cost by patient/category/ ward or clinic/drug type/diagnosis/doctor.

Maintenance of a comprehensive formulary file covering all pharmaceuti­ cal items and preparations available in the hospital. The formulary might be so structured as to assist in any future move towards generic

dispensing. Maintenance of a drug location index.

117

APPENDIX 7

(ii) Patient medication Drug ordering: Any system designed to support automatic drug ordering would have to conform with legislative requirements relating to prescrib­ ing. One might therefore envisage systems in which either the ordering process would be consequential to the issuing of a written authorisation

by the doctor or alternatively, if the doctor is to initiate the order directly, the system should respond by producing a hard copy prescription for the doctor’s signature.

Monitoring of drug orders: The drug ordering system· could be supple­ mented by automated procedures which by accessing the Formulary file, would check the consistency of the ordered drug, dosage, frequency,

duration and route. Further checks could be carried out on patient/drug and drug/drug sensitivities and the doctor alerted when any incon­ gruities are detected.

The printing of drug container labels: This could also be carried out as an adjunct to the ordering process and on a stand-alone basis in the case of prepacked medications.

Medication administration: This would involve the production of medi- • cation schedules on either a ward or nursing unit basis and also a system of logging each dosage administered to a patient. The system could also have the capacity to inform doctors (perhaps via a terminal in the doctors’

lounge) of any patients for whom current medication orders will expire within 48 hours.

Ancillary ordering: The ordering of certain drugs could also stimulate orders to other service centres such as special diets or diet holds.

Stop medication orders: These could be accommodated on an elapsed- time basis or by direction from the physician to signal the cessation of drug therapy for a patient.

Patient medication profiles and cumulative medication histories: These histories could be maintained on computer files and would provide a basis for the surveillance of drug/drug incompatibilities, the generation of medication schedules, and would provide a useful source for the deri­ vation of administrative and clinical statistics on drug usage.

(iii) Drug Control The recording of data relating to adverse drug reactions and the provi­ sion of such information to the Australian Drug Evaluation Committee might constitute an area of potential computer assistance.

Further systems might address themselves to recording and reporting on drug interactions, toxicology and incompatibilities in intravenous fluids. Drug recall procedures could ensure that on notification of deficiencies in drug batches all unconsumed dosages issued to inpatients (and perhaps outpatients) could be withdrawn.

118

APPENDIX 7

Computer programs would be utilised in assessing the results of drugs used in clinical trials.

Special attention might be devoted to the monitoring of drug reactions on particular categories of patient—e.g. assisting in research studies of of teratogenic abnormalities attributed to drugs used by a patient during pregnancy.

Maintenance of special narcotic and customs records.

(iv) Drug information

28.1.5 The development of a comprehensive drug information service, as men­ tioned, is currently the subject of study by the Chief Pharmacist at Woden Valley Hospital and it is understood that his work is prompting national interest. He envisages a drug data service comprising information on:

Generic name Proprietary name(s) Manufacturers/agents Chemical name •Type of drug

Indications Contra-indications Dosages

Side effects/adverse reactions Teratogenic effects Potentiating and negating drugs Mode of action—site of action Absorption

Excretion Serum levels—serum half life Serum protein binding Distribution in body Placental passage—degree—significance Mammary passage—degree—significance

Symptoms of overdosage Antidotes Modifications to laboratory values.

28.1.6 While such an information service would undoubtedly be of great value to prescribers and pharmacists alike it seems inappropriate to consider the devel­ opment of such a system of national significance within the confined ambit of A.C.T. health care delivery.

29 Physiological monitoring/measurement

29.1 A number of applications relating to the monitoring and/or measuring of physiological parameters have been grouped together under this heading. The areas referred to are not exhaustive and do not necessarily bear any marked

119

APPENDIX 7

resemblance to one another—some relate to on-line monitoring systems, others to automated data collection and subsequent processing and in yet others the com­ puter merely fills the role of a sophisticated calculating machine. Applications which have received a high degree of developmental support and for which a range of systems are known to be available (e.g. intensive care monitoring and ECG interpretation) have received individual attention elsewhere.

29.2 Arterial blood gas analysis: Programs may be developed to assess the respiratory and metabolic condition of patients with respiratory insufficiency. These might assist physicians in interpreting the results of tests as well as provid­ ing recommendations on the amount of buffer bases required to correct acidosis if present.

29.3 Fluid and electrolyte balance: Given certain basic physical characteristics of the patient together with data relating to the state of hydration and electrolyte picture a system could compute the fluid and electrolyte requirement and display a schedule of administration.

29.4 Pulmonary junctions: A number of systems have been developed to assist in anlysing the results of pulmonary tests. These range from on-line analysis of spirometer tests to special programs designed to perform calculations and interpret the results of raw data relating to lung mechanics and gas diffusion rates.

29.5 Blood pressure: Relatively simple devices have been developed for auto­ matically reading a patient’s B.P. and transmitting this information to a computer. These devices inflate the cuff to 30 mm of mercury over the systolic pressure and then bleed off at 3 mm of mercury per second. Both pressures are recorded.

29.6 EEG analysis: The study of electroencephalogram recordings is extremely complex and far less progress has been made in the application of computer tech­ niques to analysis and interpretation than has been achieved in the related area of ECG analysis.

30 Preadmissions

30.1 General

30.1.1 The preadmission procedure for inpatients differs markedly between medi­ cal and surgical admissions. In the former case patients are usually admitted with a degree of urgency and their accommodation is mainly dependent upon bed availability. Surgical admissions, on the other hand, are frequently elective in nature and admission is also dependent upon theatre/surgeon availability.

30.1.2 In this report many of the functions that relate perhaps more properly to the scheduling and running of operating theatres have been examined under this heading since it is current practice for the booking clerk to co-ordinate these activities.

Possible areas of use:

Hospitals. Nursing homes and other health care institutions.

120

APPENDIX 7

Possible applications:

(i) Waiting lists Waiting lists may be compiled and maintained for: Surgical Wards Medical Wards

Day Cases Obstetrics Geriatrics Psychiatry

Rehabilitation

These lists will be used as a basis for preadmission bookings and may also prove useful in advance planning and facilities scheduling (e.g. it may be necessary to reallocate theatres according to the demand for particular specialities).

(ii) Operating theatre schedules: Theatre times may be allocated by surgeon and/or speciality. It is neces­ sary to amend these schedules from time to time according to hospital policy, prevailing requirements and whenever notification of a surgeon’s intended absence is received.

(iii) Theatre bookings: Bookings may be made on the basis of urgency, position in waiting list, theatre/surgeon availability and bed availability. Special provision must be made to ensure that sufficient theatre time is made available for emer­

gency cases.

(iv) Bed bookings: For surgical cases these bookings will be made in conjunction with the theatre booking segment. In other cases beds will be allocated on the basis of urgency and position in the waiting list.

(v) Patient appointment advice: This might involve: (a) Printing of appointment slips, (b) The confirmation of bookings on receipt of advice from the patient,

(c) Notification to attending physician.

(vi) Notification to service departments: A number of service areas require advice of an impending admission. For example: Blood bank requires notification where cross matching is needed prior

to an operation which may require a blood transfusion.

Radiology should be advised where an operation is likely to require x-ray support. Physiotherapy may be advised in the case of an obstetric admission wishing to participate in prenatal exercise classes.

121

APPENDIX 7

Casualty may be informed where admission is to be via ambulance and transportation to the ward will be necessary.

(vii) Creation of nucleus patient record: It seems desirable that, at some stage during the preadmission process, possibly at booking time, a ‘current patient record’ should be added to the patient record file. This might include such information as:

Patient identification Unit record number Urgency rating Provisional diagnosis Treatment requested Admission instructions (e.g. nurses’ orders, medication, special diet), etc.

This information could be compiled from information supplied by the patient and attending physician and, in the case of patients with a pre­ vious admission history could draw information from archival files.

(viii) Cancellations: The system should handle cancellations of confirmed bookings and re­ movals from the waiting list. Resources should be rescheduled as appro­ priate. The attending physician should be notified where the cancellation is made by the patient.

(ix) Admission lists: Daily admissions lists might be produced for distribution to the admissions office, information desk and to appropriate wards.

(x) Theatre bookings lists: Operation schedules could be produced on a weekly basis for distribution to the appropriate theatres.

(xi) Nursing dependency estimates: The system should provide nursing administration with advance notifica­ tion of admissions in order to facilitate rostering of both ward and surgi­ cal nursing staff.

31 Preventive health

31.1 General

31.1.1 Computers would appear to be eminently useful in the area of preventive medicine where members of a population or a sub-set might be recalled from time to time for examination. The issuing of recall notices and follow-up reminders which can be extremely tedious if handled by manual procedures lend themselves naturally to computer based techniques. Furthermore, by analysing patient records the extent to which a particular preventive program is effective in epidemiological terms may be subjected to on-going scrutiny.

122

APPENDIX 7

31.1.2 One particular aspect that serves to differentiate these types of systems from normal ‘medical records’ systems is that they deal with the whole population whereas in the latter case a record may only be created at the point of first con­ tact. In other words it may be necessary to have each member of the population

included in the file so that the ‘at risk’ component may be identified—a cervical cytology program for instance would only be interested in females and would further restrict examination to an age range where the disease constituted a haz­ ard. For this reason community preventive medicine programs might be treated

quite separately from the general area of medical record linkage.

Possible areas of use:

Central Health Laboratories T.B. screening—Chest Clinic Child immunisation School dental service

Hospitals Health Centres G.P.s

Possible applications:

Maintenance of population files for preventive programs associated with: cervical cytology examinations; immunisations; dental examinations (school service);

T.B. screening; surveillance of high risk cardiac patients (especially those fitted with ‘Pace­ maker’ devices); etc. Issuing of patient follow up notices for screening tests. Production of statistics indicating the effectiveness of the various screening

programs with respect to incidence of the disease and/or reduction in the need for institutional care. A hospital staff preventive health system could monitor the currentness of staff immunisation and x-ray records.

Monitoring of personnel working under occupational health hazard conditions.

32 Private health facilities 32.1 Earlier in this appendix (28.1.4) the possibility was mentioned of pharmacy systems being extended to retail pharmacy outlets and similar possibilities might exist with regard to other systems and other private facilities.

32.2 For maximum effectiveness, any record linkage system involving a central index or directory or any integrated patient record system which may be estab­ lished in the A.C.T. must receive and supply information to private hospitals, nursing homes, medical practitioners, dentists, etc. This information flow could

range from a manual system to the placement of on-line terminals in each facility, connected to a central computer.

123

APPENDIX 7

33 Registration Boards

33.1 General 33.1.1 Medical, dental, pharmaceutical, nursing, veterinary and optometry regis­ ters are maintained by the Secretariat to the Registration Boards. The relatively minor nature of this task in the A.C.T. could mean that computer assistance is not warranted. However, the area would bear examination as changes have been proposed which would increase the amount of maintenance required, and other uses for any computer files which were established might become evident. These could include the production of mailing lists and management information reports.

Possible areas of use:

Commission Administration.

Possible applications:

Maintenance of medical/paramedical registers. Production of mailing lists.

34 Supply

34.1 General

34.1.1 The supply of linen, sterile supplies, disposables, hardware and stationery to wards, service departments, clinics, etc., is a function which does not have much need for computer assistance, as very little clerical work is involved. For example, at Woden Valley Hospital the ward clerks simply enter quantities onto a pre­ printed requisition form. However, any implementation of a comprehensive on-line stores and supply system, embracing all activities of the Capital Territory Health Commission, could extend into this area. Under such a system, re-ordering at the

user level could be via remote terminals if these were present for other purposes.

Possible areas of use:

Hospitals Nursing Homes Hostels Health Centres Health Laboratory District Nursing Mental Health Service Child Health Service.

Possible applications:

Provision for the ordering of supplies to interface with a stores and supply system. Access to information on the availability of stores items.

124

APPENDIX 7

35 Surgery

35.1 General

35.1.1 Much of the activity surrounding the scheduling of patients for surgery and the allocation of theatre time to surgeons has been dealt with in the section on Preadmissions. In this section we will concentrate on the recording and report­ ing of clinical patient-related information which both precedes and arises from

surgical procedures.

Possible applications:

Preoperative orders. The surgeon and/or anaesthetist might enter into the system those tests and procedures which are required to be carried out before the operation and, by interfacing with the Nurses Orders system a checklist of requirements might

be established. Alternatively, the system could maintain a file showing all standard preoperative routines required for each of the more common pro­ cedures.

Production of Surgical check list. Reports outlining the results of laboratory tests, x-rays, ECG tests, etc., could be automatically produced prior to the operation.

Issuing and reporting on stat orders. Tests and facilities required during the course of an operation (e.g. lab tests, biopsies, x-rays, blood, etc.) could be ordered via a terminal and, where appro­ priate, results displayed at the terminal.

Operating room reports. These reports include such information as: Patient and operation Surgeon and assistant

Anaesthetist Theatre sisters Date, time and duration of operation Details of count items Particulars of gauzes, tubes and catheters left in situ.

35.1.2 The maintenance of such a computer-held file would provide useful statis­ tical information on theatre utilisation, surgeons workloads and performance analysis. In addition relevant information could be included in the patient’s care plan.

Surgeon’s report and anaesthetist’s report. These might be entered into the system for inclusion in the patient’s notes. Post-operative orders.

Orders relating to intravenous therapy, physiotherapy, etc., might also be entered at the theatre so that the patient’s care plan can be modified in pre­ paration for his return from the recovery room.

125

APPENDIX 7

Changes to Schedules. Any changes to schedules arising from emergency operations or unexpected protractions could be immediately communicated to the ward.

36 Systems training

36.1 General

36.1.1 A function which could be easily overlooked in the initial planning asso­ ciated with hospital computing systems, is that of systems training. Training is needed for all staff associated with a new system or for new staff coming in to an established system, so it is not simply a once-only procedure. The amount of effort required to implement a training procedure depends on the type of system (batch or on-line), and the type of staff involved (medical, paramedical, clerical, etc.). Obviously, on-line systems affecting medical and paramedical staff are those which will require the most sophisticated procedures, with dummy files providing real-life situations. All systems are dependent on the staff using them, and many medical computing systems have failed at least partly because of user reluctance and mis­ use. Thus the effort spent in preparing training systems is both necessary and valuable.

126

APPENDIX 8

TABLE SHOWING RANGE OF POSSIBLE APPLICATIONS AND CRITERIA INFLUENCING THEIR PRIORITIES

Legend

(a) Classifications used under the heading ‘Priority’ are defined in the report (5.4.3).

(b) Under the column headed ‘Facilities Requirements’ the following codes are used:

1 System could be implemented using computing facilities outside the Com­ mission. (This normally implies batch-oriented systems.) 2 Pilot studies (possibly involving on-line applications) could be undertaken using outside facilities.

3 The system would require facilities under Commission control.

4 Low priority projects which would be unlikely to receive early attention.

127

Can only be assessed in the light of concrete proposals. Gene­ ralised statistical packages may be of use.

Since at present many ECGs are interpreted by G.P.s and other non-cardiologists this could be an area of early interaction with the private health sector. A study of the potential need for computer assistance should be set up and, if the findings

are positive, further work aimed at assessing the relative costs and merits of available packages could continue. It is impor­ tant that cardiological expertise be brought to such a study.

Whilst the adoption of automated history taking programs offers some benefits in the standardisation of records between the various health care nodes these may be offset by serious doubts about patient and/or professional acceptance. An initial

pilot study might be in order but developmental costs are likely to be high since questionnaires will have to be drawn up to suit each particular examining discipline and to accommo­ date a multi-lingual population.

The possibility of a good pay off within a short time span suggests that a high priority be accorded to this application. However, since the blood bank is unlikely to fall within the ambit of Commission responsibility it would be appropriate to

establish avenues for liaison and control.

With the exception of (e) this appears to be an area where much pioneering activity has already been carried out both in Australia and overseas. The ready availability of program pack­ ages also points to a high probability of success but develop­

mental resources might still be quite high especially if the chosen solution involves the installation of mini-computer(s). This seems a fertile area for early study.

Application

Priority

Facilities requirements

Magnitude o f Benefit

Availability of Software

Probability of Success

Resource require­ ments

la 3 High Some Good Moderate

Not

High known Moderate High

Not

High known Moderate High

Good Not known Very good Moderate

2 3 High Not Moderate High

known

2 3 High Not known Moderate High

la 1/3 High Available Very good Moderate

3 4 Not Only Moderate Very high

known experi- mental

3 1/2/ Not Some Reason- High

3/4 known able

C om m ents

7 Clinical service departments (a) Nuclear medicine— gamma camera (b) Patient diagnostic data

(Radiology) (c) Patient diagnostic data (Nuclear medicine) (d) Patient recall

(e) Automated test ordering, scheduling and reporting (f) Patient records (other than Radiology and

N. medicine)

Commercial systems (a) Personnel/payroll (b) General ledger/accounts payable

(c) Assets register/ preventive maintenance (d) Inventory control (e) Budgetary control

9 Computer-aided diagnosis

Food services (a) Menu planning (b) Inventory control (c) Requirements planning (d) Purchasing/invoice

processing (e) Cost accounting (f) Special menu processing (g) Selective menu

processing

Since much consideration has already been given to the ac­ quisition of mini-computing facilities to support activities within the Nuclear Medicine department it would seem appropriate that these studies be continued. Patient recall facilities to ser­

vice a number of clinical areas could be developed at a moderate resource cost and consideration should be given to developing a generalised patient recall system. An exploratory analysis into the feasibility of recording diagnostic data would probably receive enthusiastic user support and could well lend itself to an early study.

Policy recommendations relating to most of these component systems have already been made.

Whilst there appears to be so much conflict of professional opinion on the merits or otherwise of computer-aided diagnosis it would seem prudent to delay any developmental activity until the field becomes better established.

Whilst many American hospitals claim dramatic savings follow­ ing the introduction of computerised food service systems it is difficult not to remain sceptical. An early appraisal of existing manual systems could profitably be undertaken prior to any

systems feasibility and cost benefit analysis. Whilst certain of the sub-systems identified here might be accorded a higher priority it would perhaps be wiser to await firm policy deci­

sions regarding centralisation of food services.

TABLE SH OW ING R A N G E OF POSSIBLE A PPLIC A TIO N S AN D C R IT ER IA IN F L U E N C IN G T H E IR PR IO R ITIE S

Generalised communications facilities might well be developed as an adjunct to other real-time applications and should be considered when drawing up equipment purchase proposals.

Justification of hardware on the basis of providing only message switching facilities might be difficult. Priority could be increased if developmental costs prove marginal through a decision to implement (say) an inpatient management system.

Whilst activity analysis programs could be developed on a stand-alone basis using manually derived data they would seem more appropriately to be considered in conjunction with in­ patient management and medical records systems. Develop­

mental activity should therefore be viewed in parallel with these projects.

Whilst the technical challenge of developing record systems and record linkage facilities is extremely high the need is com­ mensurate and since successful introduction of such systems will rely very much upon correct timing it is considered that strategic planning in this area should be carried out as a matter of urgency.

Inpatient management (or Admission/Transfers/Discharges) sys­ tems have been a traditional point of entry in setting up com­ puterised hospital systems. This seems a logical approach since many other systems depend for their viability on the

existence of at least a basic inpatient management system. Whilst all the component sub-systems listed here might not be accorded the same priority for implementation it would seem appropriate to include them all in an intial study.

A vailability Resource

require­ ments

Magnitude

C om m ents Application Success Software Benefit

(a) Ordering and purchasing

(c) Circulation and loan

awareness service

(a) Patient identification

records

(c) Staff records

(e) Morbidity statistics

logical studies

(a) Student nurse scheduling

(a) Collection and dissemination of data

(c) Maintenance of nursing care plans

Probability

Some High (to Reason- Moderate 15 Intensive care monitoring able patient)

Library services

Some Fair Fair Fairly

high (b) Catalogue maintenance control (d I Indexing and current

17 Medical records

Doubtful Moderate High Very high

(b) Maintenance of medical

(d) Medical audit

(f) Enquiry facilities for research and epidemio-(g) Record linkage (h) Problem-oriented records Nursing rostering

Good Moderate Good Not known

Moderate Fairly high Not known (b) Nurse rostering Not known Integration with Moderate Fairly high Not known Not known personnel system Nursing orders

Very high Good Unlikely Moderate

patient

lb) Recording orders

Id) Unconfirmed procedures reminders

Whilst intensive care monitoring systems utilising dedicated mini-computer resources are available (particularly from the U.S.A.) they tend to be quite expensive. An alternative ap­

proach which considers only the information requirements of the intensive care ward might be considered as a more cost- effective solution.

Seems little evidence for assigning any priority.

The establishment of records system(s) impinges on many other functional areas not only within the institution but also within the regional health care system. Whilst developmental resources investment would probably be extremely high the pay-off could be commensurate and political pressures might also in­

fluence priority. The area would benefit from a lot more study than has been possible to date and moves towards developing at least skeletal systems might be judged appropriate. Develop­ ment of problem oriented record systems would depend upon

momentum towards standardisation of this concept.

Whilst student nurse scheduling might be undertaken with relatively little resource commitment and would provide a valuable point of first contact with nursing staff, the other

areas pose greater problems.

Since the only known activity in this area is experimental, the developmental costs are likely to be extremely high and risk of failure is significant, this application does not merit a high priority at this stage.

C o u ld b e e x tre m e ly ex p en siv e.

Provision of facilities mentioned here would seem particularly appropriate in the early days of Commission planning activity. Their introduction would, however, be prompted by a demon­ strated need and the availability of Commission staff skilled

in the use of the techniques.

The need for computer-based patient billing facilities seems to be receding in the light of present government policy.

Introduction of patient scheduling systems which could cover not only hospital inpatients and outpatients but might be ex­ tended on a regional basis could well be delayed pending a better appreciation of the ramifications of regionalisation.

With the exception of a ‘drug information service’ which could be viewed on a national basis the establishment of a pharmacy system seems to be very much a borderline case between priorities 1 and 2. User enthusiasm is undoubtedly keen but

two factors, the questionable availability of appropriate pro­ gram packages and the need for closer conformity in the modus operand! of the two hospitals tend to militate against assigning the highest priority.

Certain programs might be implemented with only minor re­ source commitments and a survey of the needs for such sup­ port and availability of software might profitably be under­ taken at an early stage.

The development of a Preadmissions system should be con­ sidered in conjunction with Inpatient Management. Whilst similar systems have been developed throughout the world the

availability of specific relevant program packages is uncertain.

(a) and (b) could be accorded a high priority on the grounds of minor resource commitment and an early implementation schedule.

Time does not seem ripe at the moment.

A need for assistance in this area has been expressed and could be provided at minimum cost.

No demand for such a system.

TABLE SH OW ING R A N G E O F POSSIBLE APPLICATIONS AND C R IT ER IA IN F L U E N C IN G T H E IR PR IO R ITIE S

The system would interact closely with the Nursing orders system and is therefore given the same priority. In addition, resistance from surgeons and anaesthetists could be anticipated.

This has been considered as an overhead when assessing the resource requirements of other applications.

APPENDIX 9

MINIMUM SYSTEM CHARACTERISTICS REQUIRED TO MEET NEEDS OF ‘MONASH’ SYSTEM

1 General information

1 · 1 The three systems recommended all operate in batch mode with processing occurring mainly at regular intervals of one week or more. The Personnel/Payroll system consists of a suite of approximately 30 programs of which 13 are run in sequence to produce the payroll and update the associated files with the remaining

17 being file creation, file maintenance or end-of-year type programs. Similarly, the Creditors system comprises 12 programs of which a sequence of 5 is run monthly. The Preventive Maintenance system consists of only 2 programs, run on a weekly cycle. Thus the processing has been spread over a number of programs.

In addition, processing times are small, (e.g. A complete payroll run for the largest Victorian hospital takes less than 20 minutes processing time on the B5500.) Partly as a result of this, all restarts are performed on the basis of re-running a complete program.

1.2 All masterfiles are held on magnetic tape, but use is made of on-line storage for temporary data sets within a program or a sequence of programs. At least some of these temporary data sets are accessed randomly.

1.3 Initial transaction input is either from magnetic tape, paper tape, or punched cards. Key-to-tape equipment is used to prepare transactions for the Preventive Maintenance system. Paper tape is input to the Payroll system for the country hospitals. These hospitals punch their data on paper tape and transmit it via Telex,

creating a matching tape at the computer centre. Most other data is input on punched cards.

1.4 Output is normally on a line printer, but the Payroll system does output some paper tape (containing details of errors), for Telex transmission to the hospitals. In addition, COM equipment is now available at ‘Monash’ and some of the line printer output can be produced on microfiche, if required.

1.5 All programs are written in Cobol 68 which is a reasonably, but not com­ pletely, standard version. Of the 3 systems examined, only the Personnel/Payroll system makes any use of manufacturer-written assembly language routines (this is an octal search routine used by one program).

2 Minimum hardware characteristics

Processor Storage : Up to 192K, 6 bit characters, depending on the

processor storage requirements of the Operat­ ing System and the Cobol Compiler. Largest program execution size is 50K.

Random Access Storage : 10 million, 6 bit characters.

135

APPENDIX 9

Magnetic Tape Drives or other Magnetic Media Storage (At least 1 Magnetic tape drive would be required to provide input to COM equipment if microfiche output was requir­ ed.) Card Reader Line Printer Paper Tape Punch/Reader Telex equipment

Card Punch Key-to-Tape Punch Magnetic Tapes

Backup Equipment

Appropriate quantity to compensate for any less than 4 tape drives.

4.

1 .

1, 132 characters per line.

1, 5 hole, to interface with Telex.

1 at computer site and at each organisation. (Telex + paper tape punch/reader.) 1, depending on volume of data.

1, depending on volume of data. Up to 50 x 2400' reels for each organisation, for the 3 systems under consideration. As thought necessary.

2.1 The equipment listed above is the minimum required to operate the 3 sys­ tems as they may be obtained from the Computer Study Group at Monash. The list could be altered in a number of ways with varying amounts of effort needed to amend the systems, e.g.

(a) All data and output could be transmitted by courier. This would remove need for the Telex equipment and the paper tape punch/reader. (b) COM equipment could be used to replace much of the printed output by microfiche. This would not remove the need for the printer of course, and

would require facilities for both the COM output and microfiche viewing. COM work can be undertaken by contracting firms under a government printing service contract. (c) Data input could be standardised onto one medium removing perhaps two types of data preparation equipment.

2.2 The use of Telex equipment as a means of transmitting data from the hospi­ tal to the computer centre is limited by its slow speed, and the larger Melbourne hospitals use the central card punching service which is available to them. Woden Valley Hospital is using the Telex for personnel/payroll data but it has been estimated that the transmission time for a staff or more than 650 would exceed the time available under current operating conditions. (Up to 3J hours.) Consequently this hospital is already looking towards the installation of a faster terminal which is being tested by the ‘Monash’ group. Telex costs are low, with a monthly rental of $77 and an average usage charge of $30 per month for Woden Valley Hospital, for 4-5 hours transmisison time.

2.3 The following tables set out timing details for the systems under considera­ tion, as they are run on the B5500 computer installation at Monash University.

136

APPENDIX 9

The base figures used arc for the Alfred and St. Vincent’s Hospitals in Melbourne, which have staff members of 2,200 and 1,900 respectively. The estimated times for Canberra Hospital are based on the current figure of 1,600 employees and for Woden Valley Hospital an estimate of 1,400 has been used. The figures obtained

from Monash were the processor plus input/output (P + I/O ) times. Slightly less than half of these P + I/O times can be attributed to processing. A large part of the processing time overlaps with input/output resulting in an elapsed time of approximately two thirds of the P + I/O time.

(a) Personnel/Payroll System Hospital Period P + I/O time Processing time Comments

Alfred 4 months 51-9 hours 24 hours

Canberra 4 months 39 hours 18 hours Assumes half staff

paid each week.

Woden Valley 4 months 34 hours 15 hours Assumes half staff

paid each week.

(b) Creditors/General Ledger System Hospital Period P + I/O time Processing time Comments

St. Vincent’s 4 months 10-1 hours 4-5 hours

Canberra 4 months 8-5 hours 4 hours

Woden Valley 4 months 7-5 hours 3-5 hours

(c) Assets Register/Preventive Maintenance No figures to hand.

3 Software characteristics

3.1 An operating system would be required to handle all those functions nor­ mally carried out by such a system on medium to large scale, third generation computers. It should, for example, be able to compile, link and execute jobs as instructed via a job control language; manage all data input/output; handle inter­

rupts; and provide operator communication. It should also include a Cobol com­ piler. (Some amount of program amendment would be necessary if this was not a Burroughs Cobol 68 compiler.)

4 Operating requirements 4.1 This aspect has not been examined but would obviously depend on the volume of work being processed by the systems. Peak processing times could be expected once a week for the payroll and preventive maintenance systems, and once a month for the creditors system, with a special peak at the end of the

financial year.

4.2 Program maintenance would also be required for the 3 systems and this is estimated at 52 man days of programmer effort per year for necessary amend­ ments only. This effort would be concentrated around award changes or policy changes which caused file alteration or changes to the principles upon which pro­

grams were based.

137

APPENDIX 10

CRITERIA FOR EVALUATING SUITABILITY OF SOFTWARE PACKAGES

The following checklist should not be regarded as exhaustive but is provided as a guide to the characteristics which should be considered when evaluating hospital or other computer program packages.

1 Current operational status Is the system still classed as developmental or is it fully operational and in production? If only parts of it are in production, what is the status of the remaining parts? What is the timetable for implementation of these parts? How many users does the system support and what is calculated as its limit? Can statistics on operational reliability be provided?

2 Proven use in other organisations Has the system been obtained by any other organisation and, if so, what is the status of the system in that/those organisation/s?

3 Practicability and usefulness Does the system really provide a practicable and useful solution to the problem it addresses, or does it perhaps create more problems than it solves, by requiring, say, intensive monitoring by the user staff; are the instructions and procedures available and clear; are the current users satisfied with the product, the demands it places upon them and the output it provides?

4 Asssessment of the applicability of the package in the Australian environment and especially the Australian Capital Territory It is possible that some systems developed overseas may not be applicable to the Australian environment. Messages output on the terminals may be in a foreign language, or the emphasis and pro­ cessing structure may be oriented towards a different hospital finance structure, forcing heavy penalties to be paid in unnecessary processing overheads. The medi­ cal or paramedical involvement with the system may not be practicable at the level required by the system, or may be insufficient. Prescribing and drug issue control techniques may be inadequate.

5 Availability of the package On what basis is the package available? If by purchase, is the price reasonable in terms of the efforts it represents, the develop­ ment alternatives and the probable life of the system? What rights are retained in the system by the supplier? Can a formal contract or agreement be concluded?

6 Cost of obtaining and implementing the package Apart from the purchase price, how is training in the system provided and at what cost? What other imple­ mentation and transfer costs may be expected in bringing the system up at the transfer installation? Is additional computer or computer peripheral equipment

required in order to implement? On this basis, what is the total cost of imple­ menting the package?

7 Support of the package by the supplier What, if any, support of the package is available from the supplier and what additional cost is involved? For what

138

APPENDIX 10

period of time is the support available and what other limitations are placed upon it?

8 Maintainability What computer language has been used to develop the pack­ age? What design, systems, programming and operations documents are available? What operations manuals are available? Will training be provided on the system?

9 Cost of operation Does the system require extended shift time on your com­ puter, and, if so, at what cost? Are additional operations facilities required? Is there an impact on the work value of user staff?

10 Cost of future development Has the system been designed and documented in such a way as to be open ended for future development? Is it modular in program construction? Has provision been made to allow for growth in the various component fields, core tables, file structures, etc.

11 Impact of the package on overall strategic design for development If the package is implemented, will it fit in with the overall strategic design for develop­ ment, or will it preclude the development/implementation of some other preferred system or course of action? Will the system’s conventions contravene the conven­

tions of existing or other proposed systems?

12 Hardware implications Does use of the package imply a specific brand or model of hardware? Where the system is written in a ‘business’ type programming language, has the standard language been observed to ease the task of converting the package to run on alternate equipment?

139

GLOSSARY OF TERMS

This glossary has been included in an attempt to guide the non-technical reader through the computer jargon that has been inevitable in a report of this nature. The emphasis has therefore been placed on providing thumbnail descriptions to the lay reader rather than comprehensive definitions for the initiated. Acoustic coupler A device which permits a terminal to communicate with a computer

via a telephone line using a standard telephone handset. ADP Automatic Data Processing. Relating to data processing. Analogue to Digital Converter (A/D Converter) A device that converts analogue signals (i.e. values represented by physical entities such as voltage, current, etc.)

into their digital equivalent for computer processing. Assembly language The basic practical language of a computer. It is a symbolic language in which there is a one to one correspondence between statements or in­ structions and the operation codes that the computer recognises. It differs in this

respect from high-level languages where a single statement may, after compilation, generate a sequence of machine language codes.

Audit trace A log of all messages/transactions coming into or leaving the system. These are usually stored serially on magnetic tape. Batch processing (1) Relating to the technique of executing a set of programs such that each is completed before the next program of the set is commenced.

(2) The method of processing whereby a group of transaction data is accumulated and submitted for processing rather than processing each transaction as it occurs. Contrast with ‘real-time’ processing.

Bench mark A standard problem which is used in relative evaluation of computer systems. Bit A contraction of ‘binary digit’. The smallest unit of computer information, pos­ sessing two possible states, one or zero. Central processor That part of a computer containing the circuits controlling the

interpretation and execution of program instructions. Check digit A digit (or symbol) which may be derived from and attached to a given number according to a set of rules. By applying these rules on receipt of the number and comparing the derived check digit with the one attached, the correctness of

the number can be verified. Checkpoint A point in a program at which information about the status of the system may be recorded so that the program may be later restarted. COBOL A procedure-oriented language used mainly in programming commercial and

business applications. COBOL is an acronym for ‘COmmon Business Oriented Lan­ guage’.

COM Computer Output to Microfilm. A system which permits computer output, which might otherwise be printed, to be stored temporarily on magnetic tape and subsequently transcribed by special purpose hardware onto microfilm or microfiche. Compiler A special program which converts other programs written in a higher level

language (e.g. COBOL) into a sequentially ordered machine language program capable of execution. CPU See ‘Central Processor’. Data Base A Data Base may be regarded as a non-redundant collection of interrelated

data items which provides for the integration or sharing of common data. It may be formed by combining a number of related data files and factoring out the com­ mon data elements. A Data Base need not necessarily be maintained by a computer. A Data Base Management System (DBMS) is a set of programs which are used to facilitate the creation, maintenance and protection of a Data Base. A DBMS should provide flexibility of data organisation by allowing application program indepen­

140

dence from physical storage of data. It will normally allow multiple independent users to have concurrent access to the Data Base. Direct access Relating to a storage device in which the time required to obtain a ran­ dom item of data is effectively independent of the physical location of that data.

Examples of such storage media are magnetic disks and drums as opposed to mag­ netic tape.

Disk/drum simulated memory Also called ‘virtual memory’. Addressable storage space which appears to the user to exist in core but which in fact may be located on a direct access device. The operating system undertakes the mapping and trans­ ferring between real and virtual memory. Disk storage An external storage device consisting of one or more circular magnetic

disks which rotate rapidly about their axes. Information may be recorded on and read from either one or both surfaces of each disk.

Duplex configuration One which has two distinct sets of facilities, each of which is capable of assuming the system function while the other assumes a stand-by status. Error correction code A code which possesses sufficient redundancy to enable the detection of an error and its correction if the error is of a specific kind.

File An organised collection of related records treated as a unit. (e.g. one line of a patient’s account may form an item, the complete account may form a record and the collection of all accounts may form a file).

Front end computer See ‘Satellite/parent configuration’.

Hard copy A printed copy of computer output in a visually readable form, e.g. re­ ports, listings, documents, summaries, etc.

Hardware The physical and tangible components of a computer or data processing system. Contrast with ‘software’.

Interactive Relating to an application in which each entry to a terminal elicits a re­ sponse; e.g. an enquiry system or an airline reservation system. See also ‘real-time’.

Interface The place (or places) where two different subsystems meet and interact with one another.

Interrupt A break in the normal sequence of program instruction execution usually caused by a signal from an external source, (e.g. the arrival of a new message or the completion of an input/output operation). It causes an automatic transfer to a separate program which services the interrupt and later transfers control back to the original program at the point of interruption.

K Unit of storage measurement equal to 210 or 1,024. Key-to-tape equipment A data preparation device similar to a card punch where the information is recorded on magnetic tape as opposed to cards and which may be subsequently input to the computer. Linear programming A procedure for locating the maximum or minimum of a linear

function of variables which are subjected to linear constraints. Load sharing configuration A duplex configuration where, during the period of peak activity, both computers may share the load.

Logical file A collection of logically related records, i.e. records which have an affinity independent of their physical distribution on storage media.

Message switching A telecommunications application in which messages are received by a central system, stored until the proper outgoing circuits are available and then retransmitted to their destinations. Mini-computer A generic term loosely applied to those computers which are charac­

terised by their small physical size, low cost and relatively small core capacity.

OCR Optical character recognition. The machine identification of printed (or in some cases handwritten) characters through the use of light-sensitive devices.

On-line Relating to equipment under the control of the central processor.

141

On-line system A system in which input data enters the computer directly from the point of origin and/or output data is transmitted directly to where it is used. Inter­ mediate stages such as the preparation of punched cards, paper tape, etc., are there­ fore largely avoided.

Operating system The software which is normally permanently resident in core and which controls the execution of programs by scheduling, input/output control, job accounting and various other supervisory functions.

Pattern recognition The automatic identification of shapes, forms and patterns with­ out human participation in the decision process.

Programming language A set of words, representations and syntactic rules which are applied to the construction of a computer program.

Random access Same as ‘direct access’.

Real-time A real-time system may be defined as one which controls an environment by receiving data, performing the required processing and returning the results suffi­ ciently quickly to affect the functioning of the environment at that time. Examples of such systems are airline reservations and process control. Restart To re-establish execution of a program using data recorded at a checkpoint.

Satellite/parent configuration One in which the main processor is supported by a satellite machine (slave computer or front-end computer) which may handle com­ munications tasks. The satellite computer may interrupt the main processor to re­ quest processing of messages received. Shared file configuration A system configuration in which two (or more) computers

have access to the same storage device, although not necessarily at the same time.

Simulation The representation of certain features of the behaviour of a physical or abstract system by mathematical and logical representation within a computer program. Software The set of programs and routines concerned with the operation of a com­

puter system. The definition may also be extended to embrace all documentation related to these programs. Contrast with ‘hardware’. Tape drive The physical hardware unit which controls the movement of magnetic tape past the read/write head. The most common pictures of computer systems

depict arrays of tape drives, often creating the impression that they are the com­ puter. In fact they are merely the primary storage medium and, because of their relatively slow access time, have less application to real-time systems. (Contrast with direct access storage.) Terminal (1) A site or location at which data may enter or leave the system.

(2) A device for entering and/or receiving data at the end of a transmission line. Such devices are usually equipped with a keyboard and some form of display, e.g. visual display units, teleprinters, special keyboards, transducers, etc. Twin configuration One in which two (or more) computers process all transactions and compare results. Any discrepancy indicates a failure of at least one machine. Such configurations are only found where extremely high reliability is demanded, e.g. space-craft control. Visual display unit (VDU) A terminal device comprising a keyboard and cathode ray display screen capable of displaying alpha-numeric data.

142

BIBLIOGRAPHY

A.C.T. Health Care Delivery Environment A.C.T. H ealth Services ‘Background Papers’: Internal pub. Llewelyn-Davies et al. ‘Future Health Care Services in A.C.T.’ M inister for H ealth ‘Discussion Paper on the Proposed Health Commission for the

Australian Capital Territory.’

Hospital and Health Care Systems (General) Alderson, M. R. Towards a Health Information System": Health & Soc. Serv. J., 7 July 1973 Aldred, K. et al. ‘The Systems Approach to Hospitals’: O.R.Q. Special Conference

Anon ‘What will they Zap at El Camino? The C.R.T. or the two year old M.I.S.P.’ : Datamation, Oct. 1973 Antly, R. M. ‘A utom ation: Its Impact on the Delivery of Health Care’: Comp, and Automation, Apr. 1973

Blue Cross of M innesota ‘Hospital Computer Sharing Systems': Internal pub. Brenner, Μ. H. & Weinerman, E. R. ‘An Ambulatory Service Data System’: A.J.P.H., July 1969 Dinwoodie, Η. P. & G reene, J. D. ‘Computers in General Practice’: ■ in Principles &

Practice of Medical Computing (ed. Whitby & Lutz), Livingstone, 1971 D.N.A. ‘Computer Systems for Medicine’: Diversified Numeric Applications Division of AVNET Inc. E rtel, P. Y. et al. ‘An Outpatient Data System’: J.A.M.A. (211), 1970

Feiglin, D. Η. I. & D ugdale, L. M. ‘A Widely Applicable Programming Technique for Departmental Data Storage and Retrieval’: Med. J. Aust., 22 Sept. 1973 IBM Core. ‘Data Processing at the Presbyterian Hospital in the City of New York’ : Application Brief, GK20-0518 IBM Core. ‘Medical Information Processing: the K.S. Project": IBM publication, 1969

IBM Core. ‘IBM System/3 at the Indian River Memorial Hospital’: Application brief GK20-0560 IBM Corf. ‘Data Processing at the Atlanta Southside Comprehensive Health Centre’: Application brief GK20-0535 IBM Corf. ‘H .C .S.: Admissions System’: Systems Guide LB21-0937; Program Descrip­

tion SB21-0936 .

IBM Core. ‘H .C .S.: Accounting System and Data Communications’ : General Infor­ mation Manual, GH20-1179. Macintosh, J. R. ‘A Management Reporting System’: Can. Hosp., Nov. 1973 Mather, B. S. ‘Three Stages in the Automation of a Clinical Information Network’:

Med. J. Aust., July 1973 Medelco Inc., ‘Total Hospital Information System": Manufacturers’ brochures Medoff, L. R. ‘What to Expect if your Hospital Installs a Computer’: Medical Times, July 1973 N.Z. Defartment of H ealth ‘Proceedings of the Second Seminar on Electronic Com­

puters in Hospitals’ : Oct. 1971 O'Connell, B. P. & McF arlane, A. H. ‘A Medical Care Information System: An Approach to the Computerisation of Ambulatory Patient Records’: Med. Care. (1) 1970 Perea, G. G. ‘Purchasing Shared Computer Services’: Hospitals J.A.H.A., Aug. 1973 Presbyterian H osfital N.Y. ‘Report of Data Processing 1957-1959’ Presbyterian H osfital N.Y. ‘Report of Data Processing 197.1-1972’

R ace, D. ‘Computers and Clinical Practice’: Med.J.Aust., Dec. 1970 R eilly, N. B. ‘Computers in Medicine’ : Datamation, May 1969 Saint Barnabas Medical Centre, N ew Jersey ‘Computer Applications Profile’ Sauter, K. et al. ‘The Integrated Patient Data Bank of a Hospital Information Sys­

tem’ : IBM Internal pub.

143

Saxl, J. ‘An Innovative Medical Information Storage and Retrieval System’: Hosp. Progress, Feb. 1971 Singer, J. P. ‘Computer-Based Hospital Information Systems’: Datamation, May 1969 Smith, A. L. ‘Algorithm-based Random Access Filing System Speeds Medical Aid for

F5 Million Patients’: Data Processing, Oct. 1970 Smith, A. L. ‘Total Real-time Medical Information System’: Proc. 4th Aust. Comp. Conf., 1969 South Australian Hospitals Department "Report on a Proposed Computer System

for Flinders Medical Centre’ Soutter, J. C. ‘A Regional Health Care D ata Bank for the County of Los Angeles’: IBM Medical Centre Newsletter Texas I nstitute for R ehabilitation & Research ‘Demonstration of a Hospital Data

Management System’ : 1972 T hibodaux, T. T. et al. 'Computer-based Information System’: Hosp. J.A.H.A., Mar. 1973 T homas, G. E. & N icholas, C. ‘Computer Systems for Hospitals and Communities: a

Forecast of Future D evelopm ents': in ‘Principles & Practice of Medical Computing’ Livingstone, 1971 U niversity cf California ‘UCLA Hospitals and Clinics—Data Processing Depart­ ment Application Descriptions’: 1971 University of California ‘Health Sciences Computing Facility UCLA’: Annual

Report 1971-1972 U.K. Department of H ealth & Social Security Miscellaneous background papers U.K. Department of H ealth & Social Security ‘Using Computers to Improve Health Services. A Review for the National Health Service.’ Veterans Administration, Washington ‘Pilot Automated Hospital Information

System.’ Victorian H ospitals & C harities Commission ‘Electronic Data Processing in Vic­ torian Hospitals’: 1972 Western Australian M edical Dept. ‘Specifications for the Supply, Installation and

Maintenance of a Computing System for the Perth Region On-Line Medical Infor­ mation System": 1972 Williams, L. M. & G ray, J. C. ‘The Use of Computers for Administrative Purposes in the National Health Service’: in ‘Principles and Practice of Medical Computing’,

Livingstone, 1971 Young, J. F. ‘A Conceptual Framework for Hospital Administrative Decision Systems’: Health Serv. Res., 1968

Confidentiality Anon ‘Confidentiality’: Brit. Med. J., June 1973 K edward, Η. B. et al. ‘Computers and Psychiatric Data Recording: Rationale and Problems of Confidentiality’: Comp. Psych., Apr. 1973 Morison, W. L. ‘Report on the Law of Privacy’: 1972-1973 Pryer, R. R. L. (Correspondence): Brit. Med. J., 14 luly 1973 Rhee, H. A. (Correspondence): Brit. Med. J., 11 Aug. 1973 U.S. D epartment of H ealth E ducation and Welfare ‘Records, Computers and the

Rights of Citizens’: Report of the Secretary’s Advisory Committee on Automated Personal Data Systems, 1973 Voysey, H. ‘The New Watchdogs Pick up the Scent’: New Scientist, 2 Aug. 1973

Medical Records and Record Linkage Acheson, E. D. ‘Record Linkage in Medicine—Proceedings of the International Sym­ posium, Oxford, July 1967’: Livingstone, 1967 Anderson, J. ‘Information Processing of Medical Records’ (Proceedings of the IFIP-

TC4 Working Conference on Information Processing of Medical Record): North- Holland 1970

144

Belloc, N. D. & Arellano, M. G. ‘Computer Record Linkage on a Survey Popula­ tion’: Health Services Report, Apr. 1973 Chef. R. C. et al. ‘Computer Processing of Medical Narrative D ata: Application to Vaginal Cytology’ Acta Cyt., June 1969

Davis, L. S. et al. ‘Computer Stored Medical Record’ Comp. Biomed Red. (1), 1968 D inwoodie, Η. P. & Howell, R. W. ‘Automatic Disease Coding: the “Fruit Machine” Method in General Practice’: Brit. J. Prev. Soc. Med. (27), 1973 Donahoe, A. M. ‘Medical Records—Computer System Provides Flexible Control’:

Hosp. J AHA, 16 June 1973 G abrielli, E. R. ‘How Medical Records can be Adapted for Data Processing’: Mod. Hosp., July 1973 G ledhill, V. X. et al. ‘The Problem-Oriented Medical Synopsis' Am. Int. Med. (128),

Sept. 1971 G ledhill, V. X. et al. ‘The Application of Computers to Medical R ecords: A Com­ puter System for the Storage and Retrieval of Medical Records’: Aust. Ann. Med. (1), 1970 G reenes, R. A. et al. "Recording, Retrieval and Review of Medical Data by Physician-

Computer Interaction’: New Engl. J. Med., 5 Feb. 1970. Horton, C. L. et al. ‘C A R E : A Practical System for Processing Clinical D ata’: Comp. Biomed. Res. (6), 1973 Hospital and Allied Services Advisory Council ‘Report of the Working Party on

the Feasibility of Uniform Personal Identification Systems’: HASAC Computer Committee Report 1973 H urst, J. W. ‘How to Implement the Weed System’: Arch Int. Med. (128) Sept. 1971 K irk, J. F. et al. ‘Automation of Hospital Medical Records—Data Processing’: Health Bui. (1), 1970 Mayne, J. G. et al. ‘Toward Automating the Medical History’: Mayo Clin. Proc. (43), Jan. 1973 N urnaghan, J. H. & W hite, K. L. ‘Hospital Patient Statistics’: New Engl. J. Med.,

15 Apr. 1971 N ewcombe, Η. B. ‘Record Linking: The Design of Efficient Systems for Linking Records into Individual and Family Histories’ : Am. J. Human Gen., May 1967 N ewcombe, Η. B. ‘Present State and Long Term Objectives of British Columbia Popu­

lation Study’ Cong. Human Genetics, Sept. 1966 N ewcombe, Η. B. ‘The Use of Medical Record Linkage for Population and Genetic Studies’: Meth. Inf. Med., Jan. 1969 N ew Zealand Computer Society ‘Report Investigation of a Unique Identification

System’ : 1972 N orthern Ireland Medical R ecord L inkage R esearch U nit Report No. 1, Apr 1970 Report No. 2, Jan 1971

Report No. 3, Mar 1971 Report No. 4, Mar 1972 Opit, L. J. & W oodroffe, F. J. ‘Computer-held Clinical Record System—II Assess­ m ent’ : Brit. Med. J. (4), 1970 Oxford R egional Hospital Board ‘A Medical Information System for General Hos­

pital Patients’: Research Report No. 1, Jan. 1971 T hatcher, R. A. ‘New Concepts in Design of Medical Records in the Computer E ra’: Med. J. Aust., 15 May 1971 W hitby, L. G. & Lutz, W. ‘Principles and Practice of Medical Computing’: Living­

stone, 1971

Laboratory Systems Charing Cross H ospital ‘Pilot System in the New Hospital’: Internal report F lynn, F. V. ‘University College Hospital Department of Chemical Pathology. Descrip­ tion of Data Processing System": Internal report

145

IBM Corp. ‘Shared Laboratory Information System (SLIS)’: Application Description Manual, GH20-0709 IBM Corp. ‘Laboratory Information System': Pub. No. GE20-0139 IBM Corp. ‘System/7 Application . . . Clinical Laboratory Autom ation’: Pub. No.

GK20-0491 IBM Corp. ‘A System Design for Automated Acquisition and Processing of Chemical Data in the Clinical Laboratory’: Medical Computing Applications Report IBM Corp. ‘The BACTLAB System for Clinical Bacteriology’: Medical Centre Report

No. ZZ19-7684 IBM Corp. ‘CLS—Data processing System for Clinical Chemistry Laboratories’: Medi­ cal Computing Application Report IBM Corp. ‘H.C.S.—Laboratory Information System’’: General Information Manual,

GH20-1190 Klionsky, B. et al. ‘Determination of Costs and charges for Laboratory Tests—A Computer Approach for the Hospital Blood Bank’: Transfusion, Aug. 1973 Whitby, L. G. ‘Computers in the Clinical Chemistry Laboratory’: in ‘Principles and

Practice of Medical Computing’, Livingstone, 1971 Wilson, J. ‘An on-line Multi-instrument Laboratory Computer System’: Bio-med. Comp., Apr. 1973

Automated History Taking Griest, J. H. et al. ‘A Computer Interview for Emergency Room Patients’: Comp. Biomed. Res., (6) 1973 G rossman, J. G. et al. ‘Evaluation of Computer-Acquired Patient Histories’: JAMA

(215:8), Feb. 1971 IBM Corp. ‘IBM System for Computerizing Medical Examinations, (CME)’: Pub. No. GK20-0513 IBM Corp. ‘H C S/Patient History’: Systems Guide LB21-0965; Program Description,

SB21-0964 Kanner, I. F. ‘Physical Examination with or without a Computer': JAMA (215:8), Feb. 1971 McLean, E. R. et al. ‘Questionnaire Becomes Pre-admission Tool’: Hosp. JAHA,

June 1973

Computer-aided Diagnosis De D ombal, F. T. ‘Computer Assisted Diagnosis’: in ‘Principles and Practice of Medi­ cal Computing’, Livingstone, 1971 G oode, J. K. ‘The Clinical Decision Support System (CDSS)’ IBM Medical Industry

Report, Mar. 1972

Inpatient Management and Resource Scheduling Burroughs Corp. "B.H.A.S.—Burroughs Hospital Administrative System’: General Information Manual. IBM Corp. 'IBM 360—Hospital Information System' IBM Corp. ‘Patient Scheduling System’: IBM Medical Centre Report IBM Corp. ‘Inpatient Admission, Administration, Billing and Diagnosis Registration

by Computer’: Report of International Medical Support Centre, Stockholm IBM Corp. ‘HCS/Admissions System’: Systems Guide LB21-0937; Program Descrip­ tion SB21-0936 Mather, B. S. ‘Nursing Staff Attitudes’: Aust. Nurs. J., July 1973 T homson, Μ. E. ‘H ow Computers Help Nurses’: Aust. Nurs. J., July 1973

Pharmacy Systems Derewicz, H. J. & Zellers, D. D. ‘The Computer Based Unit Dose System at the Johns Hopkins Hospital’: Amer. J. Hosp. Pharm., Mar. 1973

146

Frankenfield, F. M. et al. ‘Automated Formulary Printing from a Computerised Drug Information File’ : Amer. J. Hosp. Pharm., Mar. 1971 IBM Core. ‘A Pharmacy Control System: Uppsala University Hospital’: Medical Computing Application Report

Melrose, J. P. ‘Automated Medication Order System’: Hosp. JAHA (44), Sept. 1970 Platiau, P. E. B. et al. ‘Computer Stores Total Drug Data’: Hosp. JAHA, Aug. 1973 R iley, A. N. et al. ‘Distributive Costs of a Computer-Based Unit Dose Drug Distri­ bution System’: Am. J. Hosp. Pharm., Mar. 1973 Seibert, S. et al. 'Utilisation of Computer Equipment and Techniques in Prescription

Processing’: Drug Intelligence (1), 1967 W inters, B. H. & H ernadez, L. ‘A Computerised Drug Inventory Control System’: Am. J. Hosp. Pharm. (29), Sept. 1972

ECG Analysis

IBM Corp. ‘H.C.S./ECG System’: General Information Manual GH20-1249; Physic­ ians Guide, GH20-1265 P ipberger, Η. V. & Cornfield, J. ‘What ECG Computer Program to Choose for Clin­ ical A pplication: The Need for Consumer Protection": Circulation, May 1973 T ownsend, H. R. A. ‘The Analysis of Electrocardiogram and Electroencephalogram

Recordings’: in ‘Principles and Practice of Medical Computing’, Livingstone, 1971

Food Services Anon ‘West Penn’s Automated Menu’: Hosp. & Nurs. Home Food Management. Apr. 1967 Anon ‘The New Dimension in M anagement: Sara Mayo Hospital’: Institutions, Sept.

1966

Bozman, J. & L awrence, D. ‘New Computerised Menu Planning Service Cuts Food Costs at Kansas City Centre": Mod. Hosp. Coulter, R. ‘Food Management System": IBM Customer Executive Seminar, 1972 D avid, B. D. ‘Systems Approach is the Key to Success’: Hosp. JAHA, June 1973

G elpi, M. J. G. & F indorf, I. K. ‘Computer Plans Modified Diets’: Hosp. JAHA, July 1973 Schaum, K. D. & Sharp, J. L. ‘Patient-Oriented Dietetic Information System’: J. Am. Diet. Ass. (63), July 1973

Patient Monitoring G erbode, F. ‘Computerised Monitoring of Seriously 111 Patients’: J. Thor. & Card. Surg., Aug. 1973 IBM Corp. O n-Line Patient Monitoring at Pacific Medical Centre’: Report No.

GK20-0625

N o te : At the time of printing, the range of literature is still growing. In particular, Committee has approached a number of computer manufacturers with a view to eliciting information on relevant systems.

147