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

Planned maintenance activity on Wednesday 18 July from 8pm to 10pm AEST may impact performance of the RACGP website.

Practice standards

Computer and information security standards

Standard 4: Managing access

Our practice establishes and monitors authorised access to health information

Compliance indicators

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

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.

The compliance indicators for managing access are extensive because this is a fundamental and important area of information security and in the protection of both your practice clinical and business information. The processes involved in managing access are numerous and complex, and therefore in this matrix have been deconstructed to be as simple as possible.

Managing access compliance indicatorsLevel 1 InitialLevel 2 RepeatableLevel 3 DefinedMinimumLevel 5 Optimised
Level 4 Managed
4.1 Policy content No formal policy No complete written policy Complete written policy Complete written policy, periodically reviewed Complete written policy, reviewed annually
4.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
4.3 Access rights Identification (usernames) None Users share single username Single role username used Unique identification for all systems Multiple unique identifications for different systems
Authentication for system administrator No special username or login Same as for normal username and password Single username for all systems administration Different identification for system administration Multiple authentication methods for system administration
Authentication of users None All users share one password Group password for group user identification Individual password Two-factor authentication for health records
Functionality of role Has access to all systems and functions when logged on Has access to all systems except administration functions Group-role-based functionality, with no minimum set of accessible functions defined Group-role-based functionality with minimum set of accessible functions defined Individual restricted functions to minimum required for role
Public access Unknown Not considered Ad hoc access allowed No access Access with strong authentication and ease of use
Review of accesses Unknown Never performed Ad hoc When required Periodic review for access and review for completeness and accuracy of user information
4.4 Password maintenance Change frequency None Ad hoc change Policy-suggested frequency change Periodic change of password and immediately if it has been compromised Regular password change forced ≤-90 days and immediately if it has been compromised
Type (strong/weak) minimum length and format None Short password and words allowed Allows dictionary words >6 characters but not enforced >8 characters with alpha, numeric and special characters enforced
Reusability Not checked (i.e. unrestricted reuse allowed) Cannot reuse existing password Reuse allowed but not last one used Reuse allowed after 3 changes Reuse not allowed
Default passwords Unknown Account can be created with default or no password Forced change at first login Password change enforced at creation Password change enforced after unsuccessful login attempt
4.5 Password management Who can create/remove users (identifications) Unknown or all users Some users Only external IT support can create or remove users Multiple system administrators in practice Practice system administrator only
Reset passwords Unknown or all users Cannot be reset Only external IT support can reset passwords Practice manager or system administrator only can reset passwords Automated system for password reset using user identification
Process for removing IDs Unknown or all users remain active indefinitely User’s password changed only Users removed ad hoc Users removed at periodic review In accordance with policy, user IDs archived or removed upon leaving
Invalid access attempts Unknown or unlimited Notify after 3 invalid attempts Reject access after 3 invalid attempts and wait period for exclusion Reject access after 3 invalid attempts and reset required by user notification Reject access after 3 invalid attempts and reset required by system administration
4.6 Remote access Remote access by vendor Unknown Information systems or software vendor has uncontrolled access to whole system without confidentiality agreement in place Information systems or software vendor has uncontrolled access to whole system with confidentiality agreement in place Limited access to patient data
Confidentiality agreement in place
Information systems or software vendor access controlled by practice
Vendor default access removed at installation
Confidentiality agreement in place
Remote access for normal users Unknown All normal users have remote access using normal logins Users have remote access using different logins Remote access restricted to specific users with different usernames Disabled or one-time-only remote access sessions for a individual username
Virtual private network (VPN) Unknown or not used Group user authentication Individual user authentication Individual user authentication Client authentication (computer used is always authenticated to system in addition to user) and enforced usage for remote access
Remote access to server/files systems Unknown Open access to servers Limited to servers Remote server access limited Administrator remote access to servers only
Guest accounts Unknown Guest accounts active with default passwords Guest accounts enabled with passwords changed regularly Guest accounts disabled All guest accounts removed
4.7 Default user accounts Unknown Default accounts active with default passwords Default accounts active with passwords changed regularly Default accounts disabled All default accounts removed except for system administrator
Network access controls is dealt with in Standard 9: Computer network perimeter controls This includes renaming administrator accounts on devices, deciding on type of access control to network
4.8 Auditing Recording Unknown or access not logged Access logged Access and type of change logged for clinical information systems All logged with minimum details All access attempts to individual software logged (including date, time, ID, IP, event, action)
Review Unknown or not performed Audit not reviewed Reviewed only for checking Reviewed as needed Reviewed, analysed and reported on to meet practice policy
Retention period Not retained Retained on rolling cycle or can be deleted by users Retained in rolling cycle and read only Retained but can be deleted by software providers
Read only
Retained indefinitely (as per policy/legislation) and restricted access to read only
4.9 Initial definition and permissions management Detailed role-based access (job, title, responsibility, role) None, unknown Ad hoc (known but not documented) Detailed for main application only Detailed once at system installation for applications and operating system Determined, documented and reviewed annually for all applications and operating system (as defined in risk assessment register)
Workgroup-based (clinical team) as to what records are accessible None, unknown Ad hoc (known but not documented) Detailed for main application only Detailed once at system installation for applications and operating system Determined, documented and reviewed annually for all applications and operating system
Discretionary access: who can grant access to other health providers (e.g. specialist) to a patient’s record (practice data not PCEHR)? Unknown No one allocated Decision made ad hoc by person not directly responsible for that patient’s care Decision made ad hoc by patient’s treating healthcare professional Determined, documented and reviewed periodically
Secondary use of data access Requests assessed informally or unknown Formal assessment on individual basis
No practice policy
Practice policy established and followed
No formal documentation of decisions
Written practice policy followed, decisions documented Secondary use of data policy and decision framework followed
All requests and decisions documented as per General Practice Data Governance Council resources
Website access Undefined or informal policy on website access Written policy Written policy Written policy
Protected SSL connection
Written policy
Protected SSL connection
Adapted and reproduced with permission from Dr Patricia Williams

Helpful templates for this Standard

Template 4.1 will assist in achieving compliance.  Completion of this template will ensure you have fully documented the requirements of this Standard.

Explanatory notes

Practice team members should only have access to the systems and information required to enable them to perform their role in the practice. All practice team members require a position description that clearly outlines their roles and responsibilities and the required access to clinical and/or business information. Restricting access reduces the opportunity for accidents and errors. The practice team requires appropriate training in the relevant computer software and the potential risks before access and passwords are provided. Additionally, healthcare identifiers (healthcare provider identifier – individual (HPI-I) and healthcare provider identifier – organisation (HPI-O)) should be recorded in a secure place (for further explanation of these refer to Section 12).

The software will have the capability to provide the appropriate level of access to match the individual user role. In older systems there will be a small number of choices – such as Clinician, Nurse, or Administration. In more advanced systems there will be a permissions matrix that allows access levels to be set to suit a much larger number of practice roles. Individuals can have these further tailored to their particular roles.

Third party access (e.g. external IT consultants) for support and problem solving is an issue that requires careful consideration. This is often undertaken remotely and a great deal of trust is placed in software and support service staff. While technical support personnel will be knowledgeable in IT, they may not fully understand the sensitivity and confidentiality requirements of health information. Hence, technical support provisions should be underpinned by confidentiality agreements and the practice should ensure that the levels of confidentiality required are in alignment and enforced by the third party organisation.

Generally, there are different levels of role and responsibility-based access, such as:

  • systems administrator: this level of access is usually the highest and often is only used by IT/security trained and external service providers for the server, operating system and network maintenance functions, and software support
  • practice manager: this access usually includes administrative functionality on the financial, clinical and network systems used in the practice
  • receptionist: this level of access is for patient administration such as appointments and billing; there may be some limited access to clinical programs
  • clinical practice team members (including locums): this level of access is for use of the clinical programs. This access level may be further subdivided where delineation between the doctor, nursing and allied healthcare staff access is required
  • other staff, such as researchers, students, software vendors and other healthcare provider organisations: this level of access will vary depending on the activities the person is undertaking.

A table for recording all practice team members, their access levels and permitted software access is provided in Template 4.1.Once a policy on access has been determined (i.e. the rights, roles and permissions), then practice team members can be given appropriate authentication methods. These can be divided into the following types:

  • something you know (e.g. a password, currently the most common means of authentication)
  • something you have (e.g. a token or smartcard)
  • something you are (e.g. a biometric profile – fingerprint).

Passwords are the most common form of access authentication. All non-clinical practice staff should have their own passwords and not use a shared common password. Best practice principles are that all of the members of the practice team retain the responsibility for their own passwords and security tokens and do not share them with other members of the team; passwords should not be written down and placed near monitors Two-part authentication methods (a combination of two types of authentication) offer greater security.

A common problem in information security is the failure to remove the access rights of practice team members who leave the practice. It is important for the practice to consider the implications of practice team members who no longer work at the practice. The process for removal of access needs to be detailed in the access security policy and procedures manual. This will also form part of the policy relating to practice team members leaving the employment of the practice. A regular review of user access rights is important to help detect where omissions have occurred or when practice team members have changed roles.

In addition to internal policies that are concerned with access rights and other data handling processes, privacy laws require organisations that deal with personal information to make available to the public a policy about their data handling practices, including collection use and disclosure. Practices should obtain advice about this and other obligations under state, territory and national privacy laws, and codes of conduct and indemnity or legal advisors.

4.1 Policy content

One of the key features of information security is information can only be accesed by authorised personnel, appropriate to their role in the practice. Practices should develop a policy for who can have access to specific information and systems. This will be driven by the identification of potential system users in the risk assessment activity (Standard 2).

It is essential to comply with governing privacy principles and all relevant state, territory and national privacy laws. Restricting access to those who are authorised will protect the practice against misuse of information.

Practices will need to develop their policy, after identifying and applying a risk analysis, according to the needs of the practice. It is suggested that practices seek the support of suitably qualified technical service providers if needed.

Practice policy should be developed on levels of access to electronic data and information systems. The practice will need to establish an access and password policy that defines the user access level, password structure (number and type of characters) and the frequency with which passwords are required to be changed. All practice team members should create their own login passwords and be responsible for keeping them secure.

It is also important for the practice to consider the implications of practice team members who terminate their employment, to ensure the decommissioning of passwords, remote access logins, and the return of computer equipment, backups and entry devices (keys) to the practice.

The access control policy should include guidance on:

  • access rights
  • passwords
  • management of guest account and remote access accounts
  • suspension of access where known or suspected data breach has occurred
  • termination of practice team member’s access.

4.2 Policy communication

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

4.3 Access rights

Access to systems should be consistent with the responsibilities outlined in the role description of each member of the practice team. Each practice team member should create his or her own strong password(s) for access. Passwords should not be written where they can be obtained by other practice team members or people who have access to the premises. The system administrator’s password should never be divulged to anyone who is not authorised.

4.4 Password maintenance

Password maintenance is a challenging process. Passwords should be changed immediately if they have been or are suspected of having been compromised. The objective of this section is to raise awareness of the need to have and implement good password policy. The password policy should include the following aspects of password maintenance.

  • Practice team members have individual passwords (not generic), which are kept secret and secure. ‘Strong’ passwords are used and the practice team are trained in the importance of this.
  • Individual practice team members are assigned an appropriate access level specific to their role.
  • Default user account passwords are changed.
  • Passwords are changed periodically (using regular intervals, e.g. every 3 months, is the best practice security recommendation; however, this is difficult to manage for practices and therefore is acknowledged as a goal practices can be working towards). The longer the same password is used, the greater the risk that it will become known and then used, possibly without the user knowing.
  • A minimum length is set (i.e. number of characters).
  • A mixture of alphabetic and numeric characters and lower and upper case is used.
  • Passwords do not use familiar and family names or words that can be found in a dictionary.
  • Dates of birth are not used.
  • Passwords are not reused.
  • Passwords are not disclosed to anyone and others are not allowed to use your login.
  • Passwords are not written down and attached to screens.
  • Logins are not shared (i.e. people in the same role do not use the same username and password).

4.5 Password management

The password policy and practice should include the following aspects of password management:

  • specification of who can create and remove users on each practice information system
  • specification of who has authority to reset user passwords
  • specification that a practice team member’s access will be removed when they are no longer working at the practice
  • specification of the temporary disabling or removal of access passwords where a data breach is known or suspected.

4.6 Remote access

Management of guest accounts and remote access accounts may include:

  • the process to establish guest accounts
  • the process to remove unused or unnecessary guest accounts.

Where access to practice systems by external service providers is required, it is advisable to put in place a confidentiality agreement with anyone who works on or supports your computer system. This should include support for the practice computer system via modem or internet support. A suggested confidentiality agreement is given in Template 1.4.

4.7 Default user accounts

All operating systems and some software applications have default user accounts at installation. These should be removed where possible or the default passwords changed.

4.8 Auditing

Auditing of access to applications and information, as well as downloading information, should be enabled. This should include actions performed (access, modification and deletion) and be identifiable by individual user. The audit logs should be reviewed periodically.

4.9 Initial definition and permissions management

The following definitions and permissions management decisions should be documented. This task only needs to be done once or when changes in practice occur.

  • Detailed role-based access (job, title, responsibility, role).
  • Workgroup-based (clinical team) as to what records are accessible.
  • Discretionary access: who can grant access to others (e.g. other healthcare provider) to a patient’s record.
  • Secondary use of data access: refer to the General Practice Data Governance Council website ( for further information and a decision-making tool on who can access your data for secondary use purposes.
  • Website content and access for website maintenance and content changes.
Advertisement loading...