Your browser has 'Cookies' disabled, alert boxes will continue to appear without this feature.

Practice standards

Computer and information security standards

Standard 5: Business continuity and information recovery

Our practice has documented and tested plans for business continuity and information recovery

Compliance indicators

The compliance indicators listed in the matrix identify the specific actions that comprise good security practice for Standard 5.

It is assumed the practice will provide appropriate education and training to facilitate compliance with this Standard.

The compliance indicators at level 4 reflect the minimum level of computer and information security acceptable for this Standard. The compliance indicators for higher levels provide the basis for incremental security improvement.

Business continuity and information recovery compliance indicatorsLevel 1 InitialLevel 2 RepeatableLevel 3 DefinedMinimumLevel 5 Optimised
Level 4 Managed
5.1 Policy content No formal policy No complete written policy Complete written policy Complete written policy, periodically reviewed Complete written policy, reviewed annually
5.2 Policy communication Policy not communicated to the practice team Policy communicated verbally to the practice team Policy communicated in written format to relevant practice team members Policy communicated in written format, training provided and all practice team members have access to the policy Policy available in written format to relevant practice team members
Regular training for the practice team and communication strategy reviewed against policy
All practice team aware of the content and implications of the policy
5.3 Business continuity and information recovery plans Plans No formally documented plan Plans are informal but not documented Plans are partially developed and documented Plans are fully developed Plans are fully developed and tested
Critical business functions Identified but not documented Informally developed but undocumented Partially developed and documented Fully documented Fully documented and tested
Contacts listed and responsibilities assigned
Processes defined Identified but not documented Informally defined, undocumented Partially developed and documented Fully documented Process fully documented and tested
Additional resources Not identified Informally identified Partially identified and documented Identified but not budgeted Additional requirements for practice staff resources and equipment identified and allocated
Budget allocated
Alternative procedures (preparedness) Not assessed Alternative procedures developed ad hoc Alternative procedures identified but not documented Alternative procedures formally documented Alternative procedures formally documented and reviewed periodically for currency
5.4 Education None provided Ad hoc training Training prompted by incidents Ongoing education at practice team meetings Ongoing education at practice team meetings
Planned training (bi yearly) practical exercises
5.5 Plan testing No business continuity plan testing Business continuity plan testing ad hoc Business continuity plan testing driven by incidents only Business continuity plan testing intervals established Business continuity plan testing intervals established and specific dates diarised
5.6 Fault recording (fault log) Faults not recorded Ad hoc recording of faults Major faults recorded All faults recorded All faults recorded and fault log periodically reviewed and analysed
Adapted and reproduced with permission from Dr Patricia Williams

Helpful templates for this Standard

Templates 5.1–5.10 will assist in achieving compliance. Completion of these templates will ensure you have fully documented the requirements of this Standard.

Explanatory notes

Practical and implementable business continuity and information recovery plans are critical elements of computer and information security.

With the increasing dependence on electronic information systems and access to information, these plans contribute to good governance processes within a practice. Management and recovery from a computer malfunction or security incident needs to be planned for. A business continuity plan will help ensure business continuation, ensure less inconvenience to patients, and assist prompt recovery of systems. The objective of clear and simple plans is that practice team members fully understand the plan and what they need to do to action it when there is a disruptive event, a crisis or disaster situation. It is important that the whole practice team know their individual roles and responsibilities in such events.

The process for developing and implementing business continuity and information recovery described here is based on current established standards and has been simplified to be implementable by the practice with minimal technical assistance.

5.1 Policy content

Business continuity

A business continuity plan ensures continued practice operations when computer system failure occurs. The plan should concentrate on internal system malfunction or failure; however, the broader scenario should also be included, such as the functioning of the practice in the event of an environmental or natural disaster. This includes consideration of the transfer of information to and from the practice to other healthcare providers (pathology laboratories, radiology providers, specialists and hospitals), new e-health services (electronic transfer of prescriptions) and government bodies (Medicare).

The asset register is an integral part of the business continuity plan as it provides much of the essential information required to recover the practice computer systems quickly and efficiently. This will have been documented as part of the risk assessment process (Standard 2).

Information (disaster) recovery

An effective disaster recovery plan will bring the computer system back to working order, including the restoration of data. This is an increasingly technical and difficult area, and practices are well advised to consult a technical service provider. Some failures in the computer system can be very simple. However, a disaster implies a major computer failure such as the server being inoperable. It is very important to know quickly when a computer problem can be fixed inhouse and when it requires assistance from a technical service provider.

Data backup and restoration is one part of a business continuity plan and is referred to in this document as information recovery. Backups are an integral part of the information recovery process. Information recovery corrective procedure examples are provided in Templates 5.2–5.10.

5.2 Policy communication

The policy should be in written form and communicated to relevant practice team members.

5.3   Business continuity and information recovery plans

This section leads you through the steps required to create a business continuity plan, and details the functions, resources and procedures that are common to most general practices. The plan should be reviewed at specified time intervals (e.g. annually or if something changes such as the backup medium or procedure). Forms for recording the relevant information in a plan, together with examples, are provided in Templates 5.1–5.10.

When developing a business continuity plan, the first step is to identify the critical business functions and the resources required to operate the practice at a minimum acceptable level without functional computers. If a significant computer failure occurs, practices need to know how practice systems will be managed ‘manually’ and the information to be collected for re-entering after recovery. Therefore, the plan must include advice on how to revert to a paper-based system until the computers are functional again (e.g. prescriptions can be written on the electronic script paper) and should cover basic practice systems such as:

  • enabling clinical team members to provide adequate clinical care while not having access to electronic health records
  • appointment scheduling
  • billing
  • business financial operations (payroll, Medicare claims).

A business continuity plan should first cover the critical functions of the practice so that in the event of a crisis the practice can continue without major disruption or risk to patients and practice team members. Second, the information (disaster) recovery plan should contain the information necessary for returning the practice to its normal state and to minimise downtime. This will include using the backup as part of the recovery process.

The business continuity plan requires the creation and maintenance of an asset register that documents the hardware and software owned by the practice and details, where the computer media can be found, and who to phone for technical support. Maintaining a log of faults as they occur helps in dealing with computer problems, including ‘disasters’. The development of an information recovery plan is usually in consultation with the GPs, practice team and technical service provider. The Computer Security Coordinator is responsible for managing this task.

A fundamental principle in developing plans is that they are simple to understand and follow. In general there are three levels of response:

  • emergency (first) response: this involves protection of people and property from immediate harm
  • continuity phase: the processes and procedures to ensure the practice continues to meet its critical functions at a minimum acceptable level
  • recovery phase: the processes and procedures to re-establish normal operation.

Identify critical practice functions

These functions should include:

  • clinical and business functions
  • identifying the system normally used to undertake a task and the resources required to complete the task if the system is not available.

A further consideration is noting any critical times of the month that activities usually have to take place. This may include payroll or end-of-month processes.

Identify additional resources that will be required for continuity and recovery

A practice needs to consider what organisational capacity and knowledge it already has in order to manage and implement the strategies detailed in the plans. What additional resources may be needed? To assist in identifying possible resource requirements, these have been categorised in the tables in Template 5.2.

Document continuity and recovery processes, including alternative work procedures

This section has been structured to reflect the emergency, continuity and recovery phases, as follows.

Emergency response

The emergency and evacuation procedures will already be defined for the practice in the case of emergencies and natural disasters. First and foremost, these are in place to protect and preserve life.

Continuity phase

This phase concerns how to convert to manual procedures for critical practice functions. Each critical function in the practice requires a contingency plan so that when things go wrong the practice can continue to operate, and this includes the computer systems. Critical functions can be divided into either business or clinical. The practice needs to identify the major functions that are required to run the practice and how these will continue should the computer system be inoperable. Consider the following:

  • access to a laptop computer with copy of database on it
  • access to the contact details of the key practice staff
  • access to patient contact details
  • work-around processes (for all critical functions identified). Some procedures and examples are provided in Template 5.4.

Recovery phase

The recovery phase involves assessing the problem, taking corrective action, restoring the system, entering the backlog of information, communicating with those affected, and undertaking a post-incident review. These tasks are discussed below.

Assess the computer problem

An assessment of the computer problem should be documented and include the following items:

  • writing down or capturing (‘print screen’) any error messages
  • noting anything that changed prior to the system failing
  • checking that all power and network connections and cables are plugged in and that the devices are turned on (check that lights are on).

Perform corrective action (with or without technical support)

Complete the tables given in Template 5.5 and add any further items from past practice experience. Discuss them with your technical service provider. While these are listed as separate incidents it should be remembered that sometimes attacks have multiple components, such as malware (e.g. trojan), on your computer that leads to unauthorised access.

It is important that the practice Computer Security Coordinator knows the realistic capability of the practice to correct and recover from incidents to ensure that time is not wasted if technical assistance is required.

Restore system and reconfigure

The restore procedure is detailed in Section 7 (Information backup). The information recorded in the risk assessment (e.g. assets and their settings, users and their access levels) will be used for this. This task involves establishing procedures to test that the systems are functional. Systems checks will vary depending on the identified malfunction.

Enter backlog of information

This may need to be undertaken prior to resuming normal operations depending on the systems used in the practice and if information is required to be entered chronologically. You may need to consult with your software provider to ascertain this.

Template 5.6 lists common tasks to assist you in planning what information will need to be entered or re-entered into the computer system, how this will be done and who will undertake this task. There should be plans for both entering data that was processed manually, including re-entering data if the system had to be restored from a previous backup.

Note: In the event of short and medium term events, follow-up with external information transfer and exchange healthcare organisations may be necessary to ensure that any data that was transmitted during the time of non-operation is transmitted again.

Communicate with those affected

Practice team members, patients, other healthcare providers, technical support providers and relevant authorities may need to be informed following an incident. Use the contact list in Template 2.2.

Review following recovery

Review the reason for the problem and ascertain how the recovery was executed, update the computer set-up, document any important lessons, and update the policy and procedures manual. This step might involve modifying the software, backup process or acquiring new components. Further, consideration of insurance claims and policies may be necessary.

Assess current preparedness and actions to be taken

Assess and document (in an action plan) what needs to be put in place to support the alternative procedures and access to additional resources. This will include the following:

  • computer equipment redundancy
  • human resources
  • facilities
  • communications
  • data
  • paper records
  • technical assistance.

5.4 Education

Education and training of the whole practice team in business continuity procedures is vital, so that when a disaster occurs all practice team members know what to do and what role and responsibility they have, so they are confident they can safely and efficiently handle these adverse events. This training activity can be undertaken using practical exercises in the same way fire drills are practised. Alternatively, such plans could be points of discussion at monthly practice meetings.

Consider planning for bi-yearly practical exercises and the scheduling of regular discussion on business continuity and information recovery at regular practice team meetings.

5.5 Plan testing

Business continuity and information recovery plans should be tested at specified intervals. Determine the interval or specific dates the plans are to be tested and schedule them into the practice diary.

Business continuity and information recovery plans should be updated at specified intervals and when technological or procedural changes occur. It is important to keep the business continuity and information recovery plans current. This means updating them when new equipment is installed or when the practice procedures change.

5.6 Fault recording (fault log)

Any fault or incident should be recorded. A form is provided in Template 5.10.

Advertisement loading...