Requirements Specification (CQR1200) Consultation Draft · The Architecture Development Programme...

National Clinical Quality Registries

Requirements Specification (CQR1200)

Consultation Draft

October 2011

National Clinical Quality Registries Requirements Specification (CQR1200)

ii October 2011

National E-Health Transition Authority Ltd

Level 25

56 Pitt Street

Sydney, NSW, 2000

Australia.

www.nehta.gov.au

Disclaimer

NEHTA makes the information and other material (‘Information’) in this document available in good faith but without any representation or warranty as to its accuracy or completeness. NEHTA cannot accept any responsibility for the consequences of any use of the Information. As the Information is of a general nature only, it is up to any person using or relying on the Information to ensure that it is accurate, complete and suitable for the circumstances of its use.

Document Control

This document is maintained in electronic form. The current revision of this document is located on the NEHTA Web site and is uncontrolled in printed form. It is the responsibility of the user to verify that this copy is of the latest revision. This document has been generated using template version 1.30.

Copyright © 2011 NEHTA.

This document contains information which is protected by copyright. All Rights Reserved. No part of this work may be reproduced or used in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems—without the permission of NEHTA. All copies of this document must include the copyright and other information contained on this page.

http://www.nehta.gov.au/

nehta Table of contents

October 2011 iii

This page is intentionally left blank


iv October 2011

Table of contents

1 Document introduction ............................................................................... 1 1.1 Purpose............................................................................................... 1 1.2 Intended audience ................................................................................ 1 1.3 Scope ................................................................................................. 1 1.4 Application .......................................................................................... 1 1.5 Acknowledgements ............................................................................... 1 1.6 Questions and feedback......................................................................... 2

2 Introduction ............................................................................................... 3 2.1 Background ......................................................................................... 3 2.2 Functional overview .............................................................................. 3 2.3 Stakeholder analysis ............................................................................. 5 2.4 Scope boundaries ................................................................................. 8 2.5 Source of requirements ......................................................................... 9 2.6 Requirement attributes........................................................................ 10 2.7 Categorisation and prioritisation of requirements..................................... 11

3 Requirements ........................................................................................... 12 3.1 Business requirements ........................................................................ 12 3.2 Functional requirements ...................................................................... 18

3.2.1 Provider enrolment.................................................................. 18 3.2.2 Data collection........................................................................ 20 3.2.3 Data quality management ........................................................ 30 3.2.4 Data analysis and outcome reporting ......................................... 33 3.2.5 Data requirements .................................................................. 40

3.3 Non-functional requirements ................................................................ 44 3.3.1 Look and feel ......................................................................... 44 3.3.2 Usability and Accessibility......................................................... 44 3.3.3 Performance........................................................................... 49 3.3.4 Operational ............................................................................ 55 3.3.5 Maintainability and support....................................................... 59 3.3.6 Security................................................................................. 61 3.3.7 Legal..................................................................................... 70

nehta Table of contents

v4.0 October 2011 v

This page is intentionally left blank

nehta Document introduction

October 2011 1

1 Document introduction

1.1 Purpose

The purpose of this document is to provide a baseline of requirements for a dedicated national infrastructure for health data management for high-priority Australian clinical quality registries and to guide the development of the architectural options for the Clinical Quality Registries Project.

1.2 Intended audience

This consultation draft is provided in the public domain for review and comment.

1.3 Scope

The scope of the document relates to high level Business, Functional, Data and Non-Functional Requirements for the purpose of developing costed options for best-practice technical infrastructure for Australian clinical quality registries.

1.4 Application

The requirements contained in the document are not intended for use as compliance requirements for existing clinical quality registries in Australia. Nor are the requirements intended, or sufficiently detailed, to be used as the basis for detailed design of a clinical quality registry system.

1.5 Acknowledgements

The Australian Commission on Safety and Quality in Health Care and the National E-Health Transition Authority would like to acknowledge the considerable contributions made by staff of Australian clinical quality registries, and other experts in this field, in the development of these requirements, including:


2 October 2011

Name Organisation

Gail Adams ANZICS Centre for Outcome & Resource Evaluation (CORE)

Carl Costolloe Clinical Informatics and Data Management Unit, DEPM, Monash University

Katherine Economides Royal Australasian College of Surgeons

Sue Evans Centre of Research Excellence in Patient Safety, DEPM, Monash University

Liddy Griffith Data Management and Analysis Centre, University of Adelaide

Xaioxiang Guan Clinical Informatics and Data Management Unit, DEPM, Monash University

James Harrison Australian Institute of Health and Welfare (AIHW) - (Flinders University)

Kylie Hurst The Australia & NZ Dialysis and Transplant Registry (ANZDATA)

Bernhard Hurzeler ICM Consulting

Joyce Lim The George Institute for Global Health

Scott Miller Data Management and Analysis Centre, University of Adelaide

Denzil O'Brien Australian Institute of Health and Welfare (AIHW) & Research Centre for Injury Studies, Flinders University

Michelle Ogilvy Royal Australasian College of Surgeons

David Pilcher ANZICS Centre for Outcome & Resource Evaluation (CORE)

Malcolm Pradhan Alcidion

Chris Price National Stroke Foundation Australia

Frances Simmons Centre for Health Service Development, University of Wollongong

Patrick Steele Centre for Health Service Development, University of Wollongong

Alison van Lint ANZICS Centre for Outcome & Resource Evaluation (CORE)

Ming Zhang Centre for Health Service Development, University of Wollongong

1.6 Questions and feedback

The Architecture Development Programme within the National E-Health Transition Authority values your feedback on the content contained in the document. Please direct your questions or feedback to [email protected].

mailto:[email protected]

nehta Introduction

October 2011 3

2 Introduction

2.1 Background

Clinical quality registries (CQRs) are clinical databases that systematically collect longitudinal health-related information on the quality of care provided to individuals. They focus on conditions and procedures where outcomes are thought to vary and where improvements in quality have the greatest capacity to improve quality of life and/or reduce costs. They potentially provide a strong evidence base for determining the efficacy, safety and quality of providers, interventions, medications, devices and treatments.

The purpose of clinical quality registries is to monitor the safety and quality of health care provided to patients by systematically gathering, analysing and making widely available what is being done and the results of that clinical activity. Clinical quality registries build on data collected from events in daily health care and use this information to assess the appropriateness and effectiveness of health care and support quality improvements where required.

Currently, reliable national data to support reporting of clinically specific variations against best practice or guidelines (appropriateness of care) and to map outcomes (effectiveness of care) are scant. Where data to support such measurement are not available from existing national health information sets, this gap can be addressed by the development and operation of a number of Australian CQRs.

In November 2010, the Australian Health Ministers Advisory Council (AHMAC) endorsed Strategic Principles and Operating Principles for the evaluation of Australian clinical quality registries. They also noted that the Australian Commission on Safety and Quality in Health Care (the Commission) would draft national arrangements, including data and clinical governance for Australian clinical quality registries, and prepare costed options for best-practice technical infrastructure to be provided to Health Ministers in 2011.

This baseline of high level Business, Functional, Data and Non-Functional Requirements has been developed as an input to the development of costing options for best-practice technical infrastructure for Australian clinical quality registries (ACQRs).

2.2 Functional overview

Figure 1 (see over) illustrates the key functions performed by Australian clinical quality registries.


4 October 2011

Figure 1: Functional overview of an Australian Clinical Quality Registry

nehta Introduction

October 2011 5

2.3 Stakeholder analysis

The following table identifies key stakeholders in the governance, operation and use of information produced by Australian clinical quality registries.


6 October 2011

Stakeholder Description

Funders of healthcare Provide funding for the provision of healthcare with a concomitant interest in the quality of healthcare provision (e.g. Commonwealth, State and Territory governments, private healthcare organisations, and healthcare insurers).

Registry Management/ Governance Board

Establishes purpose and scope of registry, defines eligibility criteria, defines minimum data set, defines use of data, and oversees quality assurance activities.

Registry staff Perform operational activities of registry including provider enrolment, support participating institutions/clinicians in data collection, performs data linkages, data quality management, follow-up patient outcome data, perform data analysis, support other authorised users in data analysis, produce reports.

ICT Technical staff Provide ICT support within registries or provide support to registries through third party service arrangements.

Institutional Ethics Committee

Considers patient consent processes, requests for use of data for research purposes.

Participating Institution

Hospital or other organisation that identifies eligible patients for inclusion in CQR data collections, and provides and receives data to/from a CQR.

Participating Unit May be a unit within a hospital (e.g. Intensive Care Unit, Stroke Unit). (Refer to Participating Institution).

Participating Clinicians Healthcare provider/clinician that identifies eligible patients for inclusion in CQR data collections, and provides and receives data to/from a CQR.

Participating Staff Administrative/support staff within a Participating Institution/Unit that assist in the collection of CQR data.

Eligible Population All people within the community who meet the eligibility criteria of a specific Clinical Quality Registry.

Registry Participants Patients/people from the eligible population who meet the eligibility criteria, consent to the provision of data to a CQR and have data recorded in a CQR.

Data Recipients Individuals or organisations that receive data/reports from a CQR for the purpose of analysis and to influence improvements in clinical care. Recipients are inclusive of, but not limited to, clinicians, clinical colleges, quality assurance committees, insurers, government agencies (including State/Territory governments, Department of Health and Ageing), and funders of clinical care.

External registries/data collections

Provide data linkages to enhance the scope of data collection within a CQR and/or facilitate data quality checks.

Australian Commission on Safety & Quality in Health Care

Responsible for developing clinical quality measures.

Australian Institute of The principal health information agency in Australia responsible for

nehta Introduction

October 2011 7

Stakeholder Description

Health and Welfare (AIHW)

collecting, analysing and reporting health care information. The AIHW develops performance indicators and targets for national agreements between the Commonwealth and State and Territory governments, builds capability in data linkage projects, develops and maintains national metadata standards.


8 October 2011

2.4 Scope boundaries

The following diagram illustrates the key functions to be performed within the scope of Clinical Quality Registries described in the following requirements, and indicates functions performed by registries that fall outside of that scope.

System Boundary

Management/Governance Committee

Participating Institution/Clinician

Registry Staff

Participant

Report Recipient (includes funders of

healthcare)

Data Custodianship

Enrol Providers

Collect Data

Manage Data Quality

Follow-up Patients

Perform simple data analysis

Perform complex data

analysis

Reporting

«extend»

Figure 2: System boundary for an Australian Clinical Quality Registry system

nehta Introduction

October 2011 9

2.5 Source of requirements

The requirements included in this document have been developed through research and consultative processes.

Requirement sources include:

• Australian Commission on Safety and Quality in Health Care. Operating Principles Australian Clinical Quality Registries (2010) and Architecture and Technical Standards for Australian clinical quality registries (2010).

• Workshops and teleconferences – A series of face-to-face workshops and teleconferences were convened with staff of Australian clinical quality registries, and other experts in this field, to elicit the requirements that appear in this document.

• Registry site visits and meetings - a number of site visits and meetings have been conducted:

Date Organisation April 2011 • Centre of Research Excellence in Patient Safety (CREPS) & Critical

Care Division, Monash University (the Alfred Hospital)

• Australia and NZ Intensive Care Society (ANZICS), Centre for Outcome and Resource Evaluation (CORE) - Adult Patient Database

• Australian Stroke Clinical Registry (AuSCR), The George Institute of International Health

May 2011 • Australia and NZ Dialysis and Transplant Registry (ANZDATA), The Royal Adelaide Hospital, South Australia

• National Breast Cancer Audit, Royal Australasian College of Surgeons

June 2011 • Monash Department of Epidemiology and Preventive Medicine: Multiple registries including Bi-National Burns Registry (Bi-NBR), Australasian Society of Cardiac and Thoracic Surgeons Database Project (ASCTS)

• Australian Orthopaedic Association National Joint Replacement Registry (AOANJRR), Department of Data Management and Analysis Centre, University of Adelaide

June 2011 • Australian Institute for Health and Welfare (AIHW)

• Dr David Filby (Chair) National E Health Information Principal Committee (NEHIPC)

July 2011 • Associate Professor Jeff Flack, Clinical Director, Australian National Diabetes Information Audit & Benchmarking project (ANDIAB)

• Associate Professor Derek Chew, and Karen Uhlmann, National Heart Foundation

• Australian Rehabilitation Outcomes Centre (AROC), Australian Health Services Research Institute, University of Wollongong

August 2011

• Australia and NZ Intensive Care Society (ANZICS), Centre for Outcome and Resource Evaluation (CORE)

• Australian Orthopaedic Association National Joint Replacement Registry (AOANJRR), Department of Data Management and Analysis Centre, University of Adelaide


10 October 2011

2.6 Requirement attributes

The following set of attributes will be defined for each detailed requirement:

• Requirement ID – An identifier for the requirement which is unique across all requirements for all projects and programs across NEHTA.

• Summary – A short statement that unambiguously defines the nature of the requirement;

• Detail – A formal statement describing the capability or property of an Australian clinical quality registry, structured as "the user/Registry shall…”

The term ‘shall’ is used to ensure comprehensive inclusion and proper consideration of all requirements in a conceptual architecture and design, rather than to dictate the absolute inclusion of the requirement in the final product. Each requirement is modulated with an indication of its optionality (mandated or optional).

• Rationale - Justification as to why the requirement exists. Note that in this iteration of the requirements, a rationale has not yet been included in relation to each requirement.

• Priority – Indicates whether the requirement is considered to be a High, Medium or Low priority. These priorities will be referenced in the development of costing options.

• Release - As these requirements pertain to the development of costing options, rather than different software releases, this value will be 1.0 for every requirement in the document.

• Status - valid statuses for a requirement are:

– Open - the requirement is currently being drafted and has not been formally reviewed by stakeholders, or requires further clarification before it is ready for review.

– Proposed - the requirement is ready for review by stakeholders.

– Closed - the requirement has been accepted by the Clinical Quality Registries Expert Advisory Group.

• Type – valid requirement types are:

– Business Requirement

– Functional Requirement

– Non-Functional Requirement.

• Optionality - Refers to whether a requirement is considered Mandatory for inclusion in the development of Costing Options, or Optional. Requirements categorised as Optional are included for completeness, however will not be included in the development of Costing Options.

nehta Introduction

October 2011 11

2.7 Categorisation and prioritisation of requirements

The requirements within this document are categorised into the following areas:

• Business Requirements - these communicate, at a high level, how Australian clinical quality registries will work. They set high level parameters for the functional, data and non-functional requirements that follow.

• Functional Requirements - these include descriptions of the common functions and activities performed by clinical quality registries and business and functional requirements associated with those activities. The categories covered within the functional requirements include: general attributes, data collection, data entry/import, data quality management, patient follow-up, data analysis and reporting/data output.

• Data Requirements - these describe the (generic) type of data that are collected by Clinical Quality Registries, and requirements associated with the collection of those data.

• Non-Functional Requirements - these describe the properties or qualities that a clinical quality registry must have. The categories covered within the non-functional requirements include: look and feel, usability, performance, operability, maintainability and support, security, and legality.

Requirements have been prioritised within each category.


12 October 2011

3 Requirements

3.1 Business requirements

The following high level business requirements have predominantly been derived from the Strategic and Operating Principles for Australian Clinical Quality Registries endorsed by the Australian Health Ministers' Conference (AHMC) in November 2010. The Strategic and Operating Principles provide guidance for the development and implementation of new and existing Australian clinical quality registries.

010534 Publicly accessible eligibility criteria

Registries shall make patient eligibility criteria publicly accessible.

Legacy No R107

Priority High Release 1.0 Status Closed

Type Business Optionality Mandatory

010603 Publicly accessible data specifications

Registries shall make data specifications publicly accessible.

Legacy No R001



010617 Entire eligible population

Registries shall have the ability to collect complete registry data from the entire eligible population.

Rationale To meet Operating Principle No. 7 - Australian Clinical Quality Registries must ensure that complete registry data are collected from the entire eligible population.



nehta Requirements

October 2011 13

010598 Right to opt-out

Registries shall support the right of patients to opt-out.

Legacy No R125



010756 Informed consent

Registries shall provide participants (eligible population) with the option not to participate.



010616 Common data collection approaches

Registries shall collect data using common and systematic approaches



010718 Use of standard terminology and data specifications

Registries shall use standard definitions, terminology, data dictionaries and specifications (wherever possible) to enable meaningful comparisons and linkages (if approved by ethics committees) to other registries and databases.



010719 Publication of metadata, data dictionaries and indicators

Registries shall publish metadata, data dictionaries and indicators to a publicly available website.


Type Functional Optionality Mandatory


14 October 2011

010710 Identifying information to support registry purpose

Registries shall collect sufficient patient identifying information to support the registry's stated purpose.



010619 Avoid data collection burden on consumers

Registries shall collect data in such a way that it is not an unreasonable burden, in terms of the time and cost involved in participation, on consumers.



010621 Timely capture of data

Registries shall capture data as close as possible to the time and place of care.



010660 Monitor quality in accordance with plans

Registries shall monitor the completeness and accuracy of the data collected in accordance with quality assurance plans.



010663 Prompt identification of data quality lapses

Registries shall ensure that data accuracy checks are conducted frequently enough to enable prompt identification of data quality lapses.



nehta Requirements

October 2011 15

010664 Prompt remedy of incomplete data records

Registries shall ensure that incomplete or inaccurate data identified through data completeness checks are remedied as soon as possible.



010706 Collect co-variates for risk adjustment

Registries shall collect objective, reliable co-variates for risk adjustment to enable factors outside the control of clinicians to be taken into account by the use of appropriate statistical adjustments.



010698 Timely risk adjusted analysis reports

Registries shall report to institutions and clinicians in a timely manner on risk adjusted outcome analysis to institutions and clinicians.

Additional Notes Assumption: Ability to meet this requirement is dependent in the timeliness of business processes such as data input, quality management and readiness of data for analysis.



010716 Determining client outcomes

Client outcomes shall be determined at a time when the clinical condition has stabilised and the outcome can be reasonably ascertained.




16 October 2011

010745 Capacity to link or integrate with other registries

Registries shall have the capacity to support linkage with other datasets.

Legacy No R019; R019a



010546 Manage data in accordance with legislation and standards

Registries shall collect, store and transmit data in accordance with relevant legislation, regulation, standards and guidelines.

Legacy No R091



010580 Provision of identifiable information

Registries shall only provide identifiable information to external parties if consent has been obtained or if legislative or ethics committee approval allows for the provision of identifiable information.




010543 Availability of policies

Registries shall make data access and reporting policies available to registry users.

Legacy No R099

Priority Medium Release 1.0 Status Closed


nehta Requirements

October 2011 17

010615 Public information about registry purpose

Registries shall make access to information about the benefits or value of each registry readily available to the public.

Legacy No R001



010516 Avoid redundant data capture

Registries shall only record individual data elements once per episode to avoid redundant data capture and entry.

Legacy No R032



010622 Trained data collectors

Registries shall use appropriately trained data collectors to capture data.


Type Business Optionality Optional

010624 Use of existing data

Registries shall use data from existing sources (including administrative data) where they are of a satisfactory standard.



010662 Adequate sample sizes for data accuracy checks

Registries shall ensure that the sample size used for data accuracy checks is sufficient to produce reliable measures of data completeness and accuracy.




18 October 2011

010715 Specific case definition

Registries shall only collect information related to a specific case definition.



010717 Considerations in determining time to outcome assessment

Registries shall consider the burden and cost of data collection together with the likelihood of loss to follow-up in determining the time to outcome assessment.



010561 Produce longitudinal patient outcome information through data linkage

Registries shall be able to generate detailed longitudinal information about patient outcomes through the use of data linkage in order to monitor the effect of healthcare.

Legacy No R073



3.2 Functional requirements

The descriptive text at the beginning of each section of Functional Requirements has primarily been sourced from the Australian Commission on Safety and Quality in Health Care’s, Operating Principles for Australian Clinical Quality Registries (2010) and Architecture and Technical Standards for Australian Clinical Quality Registries (2010).

3.2.1 Provider enrolment

Provider enrolment relates to enrolling participating institutions or clinicians as providers of data to an Australian clinical quality registry.

Participating institutions, units or clinicians must be prepared to contribute information in relation to all of their eligible patients in order to avoid selection bias created by incomplete reporting either through purposeful or inadvertent exclusion of patients from the registry's data collection.

Enrolling providers in a registry requires that relevant clinicians and staff be provided with access to the registry system to enable them to collect and enter data, access data for analysis and receive reports.

The publication of eligibility criteria enables prospective participating institutions to identify the purpose of the registry and enables others to approach the registry in relation to undertaking analysis or data linkage.

nehta Requirements

October 2011 19

3.2.1.1 Enrol providers

010818 Add participating institutions or clinicians

Registries shall be able to add a new Participating Institution.

Rationale To enable additional institutions or clinicians to provide data to the registry.



010819 Associate groups

Registries shall be able to create associations between clinicians, institutions and jurisdictions.

Rationale To enable users (with higher level system privileges) to view data from all associated institutions or clinicians.



010807 Central Administration

Registries shall have a central system administration group that shall be able to appoint participating group and participating institution level system administrators.

Rationale To enable participating institutions (e.g. public/private hospitals), clinician groups and organisational groups (e.g. State and Territory government agencies, private hospital groups, clinical colleges) to create, read, and update information in accordance with their user rights.




20 October 2011

010806 Group Administration

Registries shall enable defined groups to read and run reports on data within their hospitals, jurisdiction or clinical group.

Rationale To enable, for example, State/Territory government agencies to read/receive reports pertaining to hospitals within their jurisdiction; or private hospital groups to read/receive information pertaining to hospitals within their group; or clinical colleges to read/receive reports pertaining to clinicians within their college.



010805 Participating Institution level administration

Registries shall allow Participating Institution or clinical group level administrators to be appointed to allocate user rights within the Institution or clinical group. This includes creating new user accounts and granting user privileges such as:

• Create new records

• Read records

• Update records

• Discard records.



3.2.1.2 Publish eligibility

010820 Publish eligibility criteria

Registries shall publish patient eligibility criteria on a publicly accessible website



3.2.2 Data collection

Data capture for use by a registry should be performed as close as possible in time to the relevant care event to maximise the completeness and accuracy of data. Missing data items are difficult to capture retrospectively.

It is expected that Australian clinical quality registries will continue to use a mix of paper data collection forms, electronic data entry and direct feeds from data collected as part of a patient's medical record and hospital administration systems (e.g. from pathology reports, operating theatre systems, emergency department systems and , patient administration systems). The choice of data collection methods is often determined by where the data are captured and what resources (such as access to computers) are available in particular clinical settings.

nehta Requirements

October 2011 21

For Australian clinical quality registries to ensure good quality data, meticulous attention must be given to ensuring that complete data are collected on all patients and that all eligible patients within a defined clinical population are included in the registry. If registries collect an incomplete set of patient data, strong biases in the data may occur, for example if a unit were only to record information in relation to patients with a favourable outcome.

In some registries, there is considerable value to be gained by linking data from different sources. Each Australian clinical quality registry should examine what opportunities exist to obtain broader safety and quality data through data linkage. For example, linkages with the National Death Index provide a powerful tool to assess longer term outcomes which would otherwise not be feasible to collect. Another example is linkage with infection surveillance systems to examine the rate of surgical wound infections following surgery. Detailed linked data from these registries provide information that could not have been derived from the registry alone.

Any data linkage must comply with privacy and policy and take into account the accuracy, completeness, reliability and validity of the secondary data source.

010517 Data capture options

Registries shall support the following five key options for data capture:

1. Paper collection with central data entry at registry;

2. Direct entry into registry portal via electronic form;

3. Batch upload; and

4. Direct feed from a hospital administrative or clinical information system, or another registry

5. Receipt of information through messages (e.g. HL7 pathology reports)

Legacy No R037




22 October 2011

010554 Multiple unique healthcare identifiers

Registries shall be able to record multiple unique healthcare identifiers for an individual patient.

Rationale An individual may have (for example) an Individual Healthcare Identifier (IHI), an identifier at the State level and a hospital Unit Record Number. The system needs to be able to record any or all of these identifiers. As the national IHI is introduced, this may become the predominant identifier, however records created prior to its widespread use will not have an IHI attached, and will therefore need to continue the inclusion of other healthcare identifiers.

Legacy No R016



010556 Unique identifiers for patients, providers and products

Registries shall be able to allocate a unique identifier for patients, providers and products where the Individual Healthcare Identifier (IHI) is not consistently available.

Legacy No R018



010600 Authorised contributors allowed to edit and add information

Registries shall allow authorised contributors submitting information to review and revise (edit, add to) information they have posted to the registry

Legacy No R088



nehta Requirements

October 2011 23

010891 Visibility of patient information

Users shall be able to see a patient's name or identification number and demographic information in the same location on each page. The identifying and demographic information must still be visible whilst scrolling.



010812 Access for international data providers

Registries shall enable authorised users based outside of Australia to contribute and receive data to and from the registry.

Rationale The scope of activity for some registries extends beyond the borders of Australia.

Additional Notes Access for this purpose would be restricted to pre-defined and authenticated providers.



3.2.2.1 Data Import

010523 Batch uploading

Registries shall be able to receive batch uploads of information from a source system provided to the registry in a standardised format.

Legacy No R093



010644 Establish criteria for rejecting or partially accepting records

Registries shall be able to establish criteria under which a record being imported will be rejected, or accepted with a flag attached to enable it be readily identified for review and follow-up.




24 October 2011

010643 Apply data validation checks during import

Registries shall be able to apply automated data validation checks, including simple field validation, business rules (Boolean logic and clinical logic checks) and complex computations (e.g. assays) as part of the process of importing data.



010638 Prompt if changes result from data import

Registry users shall be prompted if any data contained in existing records would be changed as a result of importing new data through an automated process.

Additional Notes Assumption: Prompt is via a report of records that would be changed, manual acceptance or checking of changes would be applied.



010763 Allow multiple episodes to be recorded

Registries shall allow data relating to multiple episodes for a single patient to be imported.



010522 Receipt of data from existing data sources

Registries should have the ability to receive/import data from existing data sources, including administrative data.

Legacy No R035



nehta Requirements

October 2011 25

010635 Access control for batch upload

Registries shall use role-based access control to enable authorised users to perform batch uploads, and prevent unauthorised users from doing so.



010762 Authorised system upload

Registries shall enable authorised systems or users to upload batches of information to the registry.

Additional Notes Assumption: Batch uploads will be initiated from the sender based on a data exchange agreement.



010640 Cross-check data being imported

Registries shall be able to cross-check large quantities of records against another set of records as part of the process of importing data to avoid record duplication.



010637 Alter records via data import

Registries shall be able to use automated data import processes to append, modify, or discard patient records.



010641 Mark mandatory fields

Registries shall be able to identify which fields within a record are mandatory.




26 October 2011

010760 Correct errors identified through validation checks

Registries shall provide users with the ability to add missing data or fix incorrect information identified through automated validity checks during data entry.

Additional Notes Assumption: Errors identification is automated, but correction of information is performed manually.



010646 Data record rejection

In the case that records are rejected, a reason can be recorded against it.



010533 Eligibility criteria

Registries shall be able to provide eligibility criteria in a computer processable form to allow systems that provide information to the registry via direct feed, to identify eligible patients based on patient events.

Additional Notes

Legacy No R029

Priority Low Release 1.0 Status Closed


010535 Automatic updates to eligibility criteria and data specifications

When data are automatically fed from administrative systems in participating facilities, registries shall provide automatic updates to those systems when changes to eligibility criteria or data specifications occur.

Legacy No R022



nehta Requirements

October 2011 27

3.2.2.2 Data Entry

010518 Scanning of simple data fields

Registries shall allow for central or local scanning of simple data fields (e.g. Checkboxes) in paper based capture to convert information to an electronic format.

Legacy No R038



010520 Barcode Scanning

Registries shall facilitate barcode scanning of patient identification labels on paper forms.

Legacy No R102



010515 Include automated data validity checks

Registries shall use automated data validity checks during data entry such as e.g. drop down selections, nested drop downs, check boxes, auto complete search clinical terminology, etc.

Legacy No R096



010759 Download printable forms

Registries shall enable users to download printable forms to aid manual data collection.



010817 Offline forms

Users shall be able to download offline forms for data entry.




28 October 2011

010519 OCR in scanning

The registry should facilitate OCR in scanning of paper forms.

Legacy No R101



010811 Logic checks and rules to guide efficient data entry

Registries shall be able to define business rules and logic checks that increase the efficiency of data entry.

Rationale To enable users to skip data items during data entry if the item is not applicable for the record being entered.



010758 Storage of paper-based data sources

Registries shall be able to store electronic copies of paper-based data collection forms.



3.2.2.3 Patient Follow up

Outcome determination is the most fundamental requirement of an Australian clinical quality registry and should be undertaken at a time when the clinical condition has stabilised and the outcome can therefore be reasonably ascertained.

Some clinical registries collect data for only a short time period, such as for a single episode of care (e.g. following admission to an Intensive Care Unit), while others follow patients until they no longer present for treatment or die (e.g. in the case of people with bleeding disorders or cystic fibrosis).

Out of hospital outcomes are commonly determined by contacting participants at a defined time after discharge and asking a small number of key questions. Alternately, registries contact the participating hospital or clinician to obtain outcome information.

Ideally, the collection and use of identifiable clinical data will enable linkage to administrative and/or other databases in order that outcome information can be collected, analysed and reported without the need to contact the patient to obtain such data. This is particularly important in order that registries can efficiently track people into the future, through multiple episodes of care and across multiple institutions.

nehta Requirements

October 2011 29

It is important for registries to endeavour to determine the outcome for the highest possible proportion of registered patients to prevent the potential for biased results.

010765 Define periods for record update

Registries shall be able to define the period in which an individual's record should be updated or completed.



010684 Prompt when record incomplete

Registries shall prompt a user when a record remains incomplete past the permitted duration for data collection/record update.

Additional Notes Prompt will occur when a user (who has entered an incomplete record) logs into the registry system.



010685 Report of incomplete record

Registries shall be able to produce a report that identifies records that are incomplete past the permitted duration for data collection/record update.



010816 Download follow-up forms

Registries shall enable users to download printable or offline forms to aid the collection of follow-up information.



010679 Lock record at case completion

Registries shall be able to lock a record (to prevent it from being edited by local users) at the point of case completion once it has passed audit checks.




30 October 2011

010682 Authorised users can unlock records

Registries shall enable authorised users to unlock records.



010687 Workflows

Registries shall support the use of generic automated workflows.

Rationale Enables production of 'To Do' lists on a user's dashboard e.g. to identify incomplete records that required update/follow up.



3.2.3 Data quality management

The potential use of Australian clinical quality registry data for benchmarking outcomes, assessing compliance with best practice guidelines etc. mandates the need for registry data to be accurate and reliable in order to maintain the confidence of providers and recipients of registry information. Australian clinical quality registries must have a robust quality assurance plan and be able to demonstrate its effectiveness. Collection of data from widely dispersed sites is a well-established risk factor for poor data quality. A continuing focus on data quality is a fundamental function of the work to be undertaken by Australian clinical quality registries.

Registries sometimes seek information from routine administrative collections to determine completeness of the registries collection, to match data with administrative collections (such as hospital statistics or deaths) to validate the registry information.

Data entry errors are not infrequent and may result from systematic errors (e.g. unclear definitions, programming errors, violation of data collection protocols) or random errors (e.g. inaccurate transcription and typing, illegible handwriting on paper forms).

Strategies for reducing such errors include cross-checking data with other data sources and incorporating range and consistency checks (front -end logic checks) in the data collection process. In addition, registries perform a range of back end data cleaning activities and should perform field audits that match reported data with clinical records in a random sample of cases, either covering all units reporting data, or targeted to areas where data quality problems have been identified or are suspected.

Completeness of data fields should be determined on a regular and frequent basis and be fed back to data collectors to enable them to retrieve outstanding data items. Reports on the performance of individual data collectors should be provided to individuals to improve data collection accuracy and reliability.

The accuracy of data entry from paper-based forms should also be regularly monitored using strategies such as double entry of a random sample of cases.

nehta Requirements

October 2011 31

Registries inform improvements in health care, in part by providing clinicians with information about how their outcomes benchmark with standards and other clinical outcomes. Data output from registries must be regarded as credible by clinicians if it is to drive change in practice. Data used to monitor the quality of care must be capable of taking into account the basic requirements of accuracy and reproducibility that underpin reliable clinical data.

010531 Define logic checks

Registries shall be able to define logic checks that constrain the information able to be entered into a field.

Rationale To prevent users, or alert them to potential errors in data entry where the error relates to combinations of data entered that are unusual and likely to be in error, for example entering a diagnosis of prostate cancer where the gender for the patient is female.

Legacy No R105



010528 In-built data validation checks

Registries shall incorporate in-built data validation checks such as data range and context sensitive validation.

Legacy No R042



010530 Record reason for overriding validity checks

Registries shall allow users to override validity constraints and annotate the reason for this action.

Legacy No R104



010558 Probabilistic matching

Registries shall support probabilistic matching of identifying information against existing registry data.

Legacy No R111




32 October 2011

010559 Search identifiers to reduce duplicate records

Registries shall allow authorised users to search patient identifying information to reduce duplicates at the point of data entry

Legacy No R112



010575 Consistency of data from different sources

Registries shall be able to produce a report on the consistency of data obtained through different sources, such as data entry versus checks against other data sources.

Legacy No R122



010661 Audit for accuracy against source

Registries shall check data accuracy in a sample of cases using audits against source records.



010821 Double entry to check accuracy

Users shall be able to double enter patient information to check the accuracy of data entry.



010764 Identification of sample for audit

Registries shall be able to identify a random sample of cases in which to conduct audits against source records.



nehta Requirements

October 2011 33

010576 Feedback on data quality

Registries shall be able to produce reports to users about the quality of data collected based on data quality standards.

Legacy No R123



010574 Production of audit reports

Registries shall be able to provide reports on the outcome of data audit checks by case, episode or facility.

Legacy No R121


Type Non-Function Optionality Mandatory

010815 Feedback on data entry error rates

Registries shall be able to provide reports to users about their data entry error rates.



3.2.4 Data analysis and outcome reporting

Registries have a fundamental requirement to report without delay on information they collect to institutions and clinicians and to the broader community, including State and Territory governments, funders and consumers.

The provision of full access to a contributor's own data and the associated reports (e.g. via real-time web-based data access) can act as a strong incentive for participation in a registry.

Evidence suggests that quality improvement is driven by the provision of outcome data to health care providers, hospitals, health jurisdictions, professional accreditation and the public.

Registries inform improvements in care, in part by providing clinicians with information about how their outcomes compare with clinical guidelines, standards and other clinical outcomes. To be effective in driving change, clinical registries must be able to provide reports as soon as possible after episodes of care.

Delayed reporting lessens the clinical value of registry data, because over time the relevance of the findings to contemporary clinical care are reduced.

Having good quality data is not, in itself, sufficient to improve quality of care. Systems must be in place to ensure that data is analysed in a timely manner with clinical interpretation on findings, and then fed back to appropriate personnel/bodies to ensure that appropriate action occurs.


34 October 2011

Registries routinely analyse data and provide timely reports to clinicians and relevant stakeholders. Outputs from CQRs might include warning signals which identify when performance falls below pre-determined levels to enable proactive monitoring of the provision of care. Data need to be analysed to identify unexplained variance and outliers. Often such data are presented graphically to aid in interpretation of findings.

In determining whether quality of care differs across health care settings, CQRs need to adjust for variation in patient outcomes that result from differences in patient characteristics that are outside the control of the healthcare providers. When outcomes are compared amongst institutions or when attempts are made to investigate poor outcomes, it may be appropriate that these factors are taken into account by applying appropriate statistical adjustments. Risk adjustment is the statistical process of identifying and adjusting for variation in outcomes resulting from differences in patient characteristics or risk factors.

Analysis of CQR data may include:

• Descriptive reporting of process or outcome variance

• Benchmarking

• Assessment of outcome data against minimum procedure volume

• Post-market surveillance of devices and of new and existing technology

• Cost-benefit, cost-utility and cost effectiveness assessment.

Much of this type of analysis is generally complex and often undertaken using specialist statistical software packages.

010579 Different report formats

Authorised users will be able to print reports, and/or save the results in HTML and PDF formats.

Legacy No R070



010571 Access to restricted reports

Registries shall implement business rules and special permissions relating to access for restricted reports.

Legacy No R115



nehta Requirements

October 2011 35

010604 Secure access to reporting from central registry

Authorised users shall be able to access reports from the central registry, for which they have access rights, through a secure portal.

Legacy No R003



010752 Record authorisation to provide identifiable data

Registries shall be able to record authorisation details when providing identifiable information to external parties.

Legacy No R116



010606 Web access to reports

Registries shall provide secure access for authorised users to standard and ad hoc reports produced by registry staff via a secure web interface.

Legacy No R067



010814 Patient summary

Users shall be able to produce an abstract of information included in the registry that pertains to an individual patient.

Rationale To enable registries to provide patients with the opportunity to review data held in the registry that pertains to them.




36 October 2011

3.2.4.1 Produce regular reports

010694 Generate standard reports

Registries shall be able to generate scheduled/routine standard reports to be sent to identified institutions and clinicians.



010566 Scheduled reporting

Registries shall enable authorised users to produce scheduled reports through selection from available reports, parameters and pre-set frequencies (for example, weekly).

Additional Notes

Legacy No R069



010567 Individual facility reports

Registries shall be able to produce reports for a facility that contains only data that they have contributed. These reports may contain identified data.

Legacy No R074



010568 Benchmark reports

Registries shall be able to produce reports that enable comparisons of de-identified aggregated data against peer group benchmarks by facilities, and by regions (including by jurisdiction and national level).

Legacy No R075



nehta Requirements

October 2011 37

010569 Clinical and epidemiological reporting

Registries shall support clinical and epidemiological reporting

Legacy No R113



010573 Coverage of eligible population report

Registries shall be able to produce a standard report on the proportion of eligible patients participating in the registry (by facility and region), against a target indicator.

Legacy No R097



010700 Contributing units can produce centrally configured reports

Registries shall enable authorised users in participating units/institutions and jurisdictions to produce centrally configured reports of their own unit's/institutions/jurisdictions data to enable monitoring of clinical care.

Additional Notes State government agencies need to be able to produce a report for all participating institutions in the State; Private healthcare organisations to produce reports for all healthcare facilities within its group; and Industry groups to produce reports pertaining to stakeholders in their industry.



3.2.4.2 Export data

010577 Export of unit record data

Registries shall be able to export unit record data in delimited format for approved purposes.

Legacy No R039




38 October 2011

010578 Default format of unit record data export

Registries shall export unit record data using de-identified data as the default format.

Legacy No R041



010547 Ability to export data for research purposes

Registries shall enable information to be exported for research purposes, once the necessary approval has been obtained.




010751 Ability to record purpose of data export

When information is exported for research purposes, registries shall be able to record the purpose for which the information is to be used.

Legacy No R020; R020c



010754 Data extraction to be audited

Registries shall only support data extraction of identifiable information via the user interface, to enable auditing.

Legacy No R116



nehta Requirements

October 2011 39

010753 Encrypt exported identifiable information

Registries must encrypt identifiable information at the point of export.

Legacy No R116



010696 Compatibility of data extracts with statistical packages

Registries shall support secure extract of data in formats compatible with major statistical packages.



3.2.4.3 Data Analysis

010688 Ad hoc data analysis available to participating units

Registries shall enable participating units/hospitals, to undertake ad hoc analyses of their own unit's/patient's data.



010689 Define parameters for ad hoc reports

Registries shall be able to define parameters, such as date ranges, filter criteria, sort criteria that are specific to a particular ad-hoc report.



010691 Use report parameters to generate ad hoc reports

Registry users shall enter information into pre-defined report parameters to generate ad hoc reports.




40 October 2011

3.2.5 Data requirements

For Australian clinical quality registries to provide the maximum value to the health system they should focus their core data collection on the essential elements required to service their main purposes. Experience has shown that registries that impose extensive data requirements that impose a burden on data providers are impractical to sustain in the long term. For this reason, in considering what measures should be used to assess performance, clinical quality registries need to ensure that they only collect data relating to the specific purpose of the registry.

The core data set from an Australian clinical quality registry must consist of data elements that are recorded in the same way using the same definitions across different institutions. Collecting data items that do not conform to national definitions limits the utility and comparability of the data.

Data elements must be capable of being easily and uniformly collected from the primary data sources at every site. The format in which data is captured should be standardised to enhance its ability to link with other databases.

Person

• Identifying information

• Dates of admission/operation/discharge

• Demographics

• Other information (age, sex) required for risk adjustment

• Participating unit/hospital

Disease or Condition

• Principal diagnoses and co-morbidities

• Results of key diagnostic tests

• Severity

Intervention

• Principal treatments provided

• Elements of clinical care provided

Appropriateness

• Proportion of patients admitted to a specific type of unit

• Proportion of patients who received a specific type of test

• Treatment in the acute phase and at discharge

Outcomes

• Survival time

• Death

• Length of hospital stay

• Patient reported outcomes

• Specific outcome indicators e.g. Time from primary (initial) procedure to first revision procedure.

nehta Requirements

October 2011 41

010711 Use of Individual Healthcare Identifiers

Registries that require individually identifiable data shall have the capacity to use national Individual Healthcare Identifiers.



010570 Specify when record is included in reports

Registries shall be able to specify the stage of record completeness (e.g. provisional or final) at which the record can be included within reports).

Legacy No R114



010595 Record that patient has been informed of participation

Registries shall be able to record that the patient has been informed of the inclusion of their data in the registry.

Legacy No R094



010596 Record patient decision to opt-out

Registries shall be able to record that the patient has opted-out of participating in the CQR at both a global and episodic level.

Legacy No R095




42 October 2011

010774 Data definitions

Registries shall maintain data definitions and descriptions for each data element and its usage.

Rationale To reduce the chance of multiple meanings and interpretation of data captured.



010585 Retire data elements

Registries shall be able to retire registry data elements, to ensure information that is no longer relevant or required for relevant analysis are deactivated (and no longer collected).

Legacy No R050



010775 Time variant data

Registries shall maintain data in such a way that enables the time period of data capture to be identified.



010586 Date stamp business rules

Registries shall have the ability to date stamp Business Rules.

Legacy No R117



nehta Requirements

October 2011 43

010776 Reference data integrity

Registries must support 'ageing of metadata' by maintaining accurate links with reference data over time.

Rationale Reference data must be made obsolete if not current, but never deleted (or links to data broken). Changes to reference data must result in the creation of new reference data to avoid loss of context for data associations.



010707 Record opt-out notification

Registries shall alert users that a patient has opted-out each time that patient's eligibility identifies them for recruitment.



010708 Flag when patient has opted-out

When the patient has opted-out, registries shall keep the patient identity and automatically flag that the patient should not be followed-up or recruited in the future.



010611 Support for data retrieval

Registries shall store data in a retrievable form with data descriptions and data structures.

Rationale To ensure that data is future-proofed and able to be retrieved and interpreted in the future.

Legacy No R011




44 October 2011

010777 Reference data sources

Registries shall clearly identify sources of reference data as well as reference data currency in their data dictionary.

Rationale To allow for timely maintenance of reference data.



3.3 Non-functional requirements

3.3.1 Look and feel

010639 Site branding

Registries shall be able to support configurable branding (e.g. logos, colour themes, version numbering, copyright information).

Rationale Funders/sponsors of registries may require acknowledgement/recognition of their support, governance etc.

Also provides a recognisable branding for a registry that enables users to identify the registry.

Legacy No LF001



3.3.2 Usability and Accessibility

3.3.2.1 General

010602 User Friendly

Registries shall ensure that user interfaces are intuitive and easy to use.

Fit Criteria Users should be able to navigate the system and access key system functions with minimal training and support.

Additional Notes

Legacy No R130



nehta Requirements

October 2011 45

010647 Support for keyboard and mouse input and navigation

Registries shall support the use of keyboard and mouse input and navigation.

Legacy No UA002



010766 Windows Navigation

Registries shall use navigation aids (e.g. menus, tabs, breadcrumbs) to aid user navigation between windows and forms.

Rationale To ensure that users can get to every main page from every other main page using site wide navigation and searching facilities (for deep hierarchies).

Fit Criteria Users should be able to navigate between main pages in one or two clicks.



010642 Web browser compatibility

Registries shall be able to support multiple web browsers and will include backwards compatibility to popular browsers. Specifically those that still have a market share usage of more than 5%.

Fit Criteria Use StatCounter Global Counter as the measure.

Additional Notes At 15 August 2011, the browsers that need to be supported are:

• Internet Explorer for Windows

• Google Chrome

• Firefox for Windows

• Firefox for OSX

• Safari for OSX

Supported set needs to be compatible with hospital 'legacy' environments.

Legacy No UA001




46 October 2011

010649 Interactive user support on each page

Registries shall incorporate the delivery of context sensitive information to users in relation to each page to assist them in the use of the system.

Legacy No UA004



010744 Interactive user support for each field

Registries shall incorporate the delivery of context sensitive information (e.g. tool tips, interactive pop-ups) to users in relation to each field to assist them in the use of the system.

Additional Notes Interactive pop-ups will be provided in key fields where there is a need to provide user guidance.

Guidance in relation to 'non-key fields' will be available on demand.

Legacy No UA005



010767 Screen resolution

Registries shall support a screen resolution on web pages equal to or higher than 1024x768.

Rationale According to W3C statistics only 1% of sample population use 800x600 resolution screens.



010648 Use of touch screens

Registries shall support the use of touch screens.

Legacy No UA003


Type Non-Function Optionality Optional

nehta Requirements

October 2011 47

010650 Ability to reduce the level of interactive support

Registries shall enable users to reduce the amount of context sensitive user support information that is displayed as users become more familiar with the system.

Legacy No UA006



3.3.2.2 Data entry import

010651 Keyboard only input and navigation for registry staff

Registries shall support the use of keyboard only input and navigation to support efficient and accurate data entry.

Rationale Important for registry staff who need to maximise their efficiency at data entry.

Legacy No UA007



010652 Usability for non-registry staff

Registries shall support a level of usability for data entry/import functions that is suitable for "familiar users" who use the same CQR often, as opposed to casual users who only use the specific CQR once or twice.

Rationale Staff in participating institutions who contribute data to the registry will become regular users of the CQR, but will not be as expert as registry staff whose job it is to interact with the registry system on a frequent/daily basis.

Legacy No UA008




48 October 2011

010653 Training expectations

Registry users (participating data providers) performing data entry functions shall only require basic training.

Legacy No UA009



3.3.2.3 Internal Registry functions (Data management, analysis, follow-up collection)

010657 Usability for registry staff

Registries shall support a level of usability for registry staff that is suitable for expert users of the system who use the system on a frequent/daily basis.

Legacy No UA011



3.3.2.4 Public facing system components

010659 Supported language

Registries shall support the use of the English language.

Additional Notes Workshop participants indicated lack of a current intention to support the use of multiple languages, although this may be required over time.

Legacy No UA013



nehta Requirements

October 2011 49

010658 Accessibility of publicly available information

Registries shall move towards being accessible to people with physical impairments (such as colour blindness) by demonstrating to what level they comply with the Web Content Accessibility Guidelines (WCAG) 1.0.

Rationale Mandatory requirement for all Australian Government websites. Australia.gov.au is currently compliant to Level A of the Web Content Accessibility Guidelines version 1.0 standard.

Additional Notes WCAG adherence is substantially more difficult to achieve for interactive pages than static pages. Registries should aim to move from Level A to Level AA compliance over time. It is anticipated that some content on Registry sites will be accessible to AAA level.

Legacy No UA012



3.3.3 Performance

3.3.3.1 Capacity

010667 Capacity-Number of provider institutions

Registries shall have the ability to support up to 1400 participating institutions.

Additional Notes 1400 =approximate number of public + private hospitals and day units in Australia.

Legacy No P001



010668 Capacity-size of eligible population

Registries shall have the ability to collect data in relation to an eligible population of 300,000 per annum.

Additional Notes 300,000=estimate of highest expected number of cases for a particular condition, procedure, management by a particular healthcare resource (e.g. ICU). Based on number of births in Australia per annum.

Legacy No P002




50 October 2011

3.3.3.1.1 Data entry/import

010669 Data entry peak transaction rate

Registries shall have the ability to support 4200 data entry transactions per hour.

Additional Notes 4200 =estimate of the highest number of transactions that a registry would need to process in an hour (based on no. of provider institutions (1400) and estimated number of concurrent users per institution (3)).

Legacy No P003



010779 Concurrent and logged in users

Registries shall be able to support 7000 logged in users and 5600 concurrent users.

Rationale To assist in capacity planning and sizing.

Additional Notes Based on 1400 institutions x 5 logged in users (7000). 1400 institutions x 4 concurrent users (5600) (assume 3 doing data entry + 1 reporting per institution).

Expected growth over five years - to be determined.



3.3.3.1.2 Internal registry functions

010678 Concurrent users

Registries shall support up to 40 concurrent registry staff users to support data entry/import functions, quality management, data analysis and internal report production.

Additional Notes 40=estimated concurrent number of registry staff for a single registry. Base on current largest registry multiplied by 2.

Legacy No P012



nehta Requirements

October 2011 51

3.3.3.2 Scalability and extensibility

010671 Point to digital images

Registries shall have the ability to point to the location of a stored image.

Additional Notes Some current registries store images within the registry system, however Working Group members agreed that images didn't necessarily need to be supported inside the system (due to significant potential additional storage costs). The cost of image storage was considered not to be a generic requirement for all registries, but could be added where relevant for specific registries.

Legacy No P005



010583 Addition of data elements

Registries shall be able to add data elements to the registry data set either permanently or for a specified period of time.

Legacy No R010



010672 Storage of digital images

Registries shall store digital images.

Additional Notes Some current registries store images within the registry system, however Working Group members agreed that images didn't necessarily need to be supported inside the system (due to significant potential additional storage costs). The cost of image storage was considered not to be a generic requirement for all registries, but could be added where relevant for specific registries.




52 October 2011

3.3.3.3 Longevity requirements

010670 Period of record retention

Registries shall support the retention of active records over 20 year periods to support longitudinal data analysis. After 20 years, records will be archived, but still be available for analysis.

Legacy No P004



3.3.3.4 Reliability and availability

010693 Support for partially saved data

Registries shall enable users to close a record that is being added or modified, save partially entered data and return the user to the record in a subsequent session.



010593 Backup facilities and procedures

Registries shall ensure that appropriate (relative to assessed risk) backup facilities are provided and backup procedures implemented.

Legacy No R013



010781 Frequency of backup

Registries shall be able to perform scheduled backups to meet availability requirements (:

Additional Notes Describe how often backups need to be performed e.g. every 15 minutes, every hour; when are full vs. incremental backups to be performed.

Legacy No MS001



nehta Requirements

October 2011 53

010782 Backup retention

Registries shall keep backups to support the requirements for:

• 010670 Period of record retention

• 010674 Recovery time

• 010673 Loss of data following disaster recovery

• 010594 Disaster recovery procedures and facilities

Additional Notes How long does each backup need to be kept for?

Legacy No MS002



010594 Disaster recovery procedures and facilities

Registries shall develop appropriate disaster recovery procedures and associated infrastructure (e.g. failover and redundancy)

Legacy No R014



010673 Loss of data following disaster recovery

Registries shall tolerate the loss of not more than one hour of data loss following disaster recovery.



010695 Continuation through validity checks

Registries shall save data that does not meet business validation rules.

Legacy No OP006



Related Items Req # 010813. Flag to indicate data that do not meet business validation rules (Child)


54 October 2011

010813 Flag to indicate data that do not meet business validation rules

Registries shall flag items for follow-up where data were saved that did not meet business validation rules.



Related Items Req # 010695. Continuation through validity checks (Parent)

3.3.3.4.1 Data entry import

010674 Recovery time

Registries shall recover data entry and data import functions no later than 48 hours following a loss of system availability.



010675 Availability for data entry

Registries shall provide 24/7, system availability to participating data providers under normal conditions. . In the event of failure the requirements for: Recovery time requirement (010674); and Turnaround time for critical production bug fixes (010785); will apply.

Additional Notes Expected usage by data providers is continual, around the clock in accordance with hospital operating times and shift rosters.

Legacy No P009



nehta Requirements

October 2011 55

3.3.3.4.2 Internal registry functions

010677 System availability

Registry systems shall provide 24/7 system availability in relation to functions performed by registry staff, with peak usage expected between 8am and 6pm. In the event of failure the requirements for: Recovery time requirement (010674); and Turnaround time for critical production bug fixes (010785); will apply.

Additional Notes Peak times are expected at the end of each week, month, year and financial year.

Legacy No P011



3.3.3.4.3 Reporting

010680 Minimal impact of reporting on other registry functions

Registries shall ensure that the use of reporting and data extraction (output) functions will have minimal impact on other registry functions such as data entry, data quality management, data analysis and other reporting functions.

Legacy No P013



3.3.4 Operational

3.3.4.1 General

010690 Support for portable devices

Registries shall support the use of portable devices.

Additional Notes This capability may be required over time, however in the short term; the design does not need to accommodate the use of portable devices.

Legacy No OP003




56 October 2011

010692 Data Centre standard

Registries shall be housed in an environment that meets the requirements of a Tier 2 data centre (TIA-942 Telecommunications Infrastructure Standard for Data Centres).

Additional Notes A data centre is a facility used to house computer systems and associated components, such as telecommunications and storage systems. It generally includes redundant or backup power supplies, redundant data communications connections, environmental controls (e.g. air conditioning, fire suppression and security devices).

Legacy No OP004



3.3.4.2 Integration

010770 Use of standards for demographic information

Registries shall use the AS5017 Health Care Client Identification standard to support the interchange of participant demographic data between health information repositories.

Rationale To provide commonality, translation and transformation of participant demographic information when required.



010601 Metadata to support local system design

Registries shall maintain and make accessible, a catalogue of metadata to support software vendors in the design of local systems that interface and interact with registries. The catalogue shall include data element definitions and cross references to reference data.

Legacy No R012



nehta Requirements

October 2011 57

010560 Employ standard to support data linkage

Registries shall employ technical and data information standards that support data linkage to, or eventual integration with, other disease and procedure registers or other databases.

Legacy No R019; R019b



010608 Consistent interface and integration design.

The design of interfaces and integration shall be consistent across registries.

Legacy No R031



010683 Interfaces for receiving data

Registries shall provide interfaces that enable external parties to 'push' data to the registry.

Additional Notes For example: from hospital-based systems that contain demographic or clinical data (e.g. patient administration systems, electronic medical record systems).

Legacy No OP001



010780 Interfaces to third party sources

Registries shall provide interfaces to third party sources that enable registries to consume data 'pulled' from those sources.

Rationale To enable, for example, linkages with population-based registries to extract reference data e.g. National Death Index.

Assumption: Manual intervention will be used to initiate these linkages.

Legacy No OP002




58 October 2011

010769 Use of health industry standard terminologies

Registries shall use Australian health industry standard terminologies (e.g. SNOMED) to support data import and export to other health information systems.



010771 Health documents exchange

Registries shall use the Clinical Document Architecture (CDA) to encode and structure clinical documents for exchange.



010772 Use of standard data exchange mechanisms

Registries shall adopt agreed Australian standards for healthcare information interoperability.



010773 Data exchange agreements and contracts

Each data provider and consumer shall have a data exchange agreement and data exchange contract detailing the specific data being exchanged and how it interfaces.



010768 Data transformation

Registries shall support data mapping and transformation between different registers and datasets through visual interfaces. Transformation should be possible using configuration files.

Additional Notes For example, if a registry received a file from a hospital, they might need to map the data structure from the hospital file to the registry's data structure/data element format.



nehta Requirements

October 2011 59

3.3.5 Maintainability and support

010584 Changing data requirements and standards

Registries shall be able to change data elements and health information standards (e.g. ICD10) over the life of a registry.

Rationale To ensure the ability to respond to changes over time

Additional Notes

Legacy No R049



010783 Expected frequency of major upgrade

Registries shall have the ability to support major upgrades of applications and databases every 3 years.

Legacy No MS003



010784 Expected frequency of minor upgrade

Registries shall have the ability to support minor upgrades of applications and databases every 3 months.

Legacy No MS004



010785 Turnaround time for critical production bug fixes

Registries shall have a turnaround time of 12-24 hours to enable correction of critical bugs in production.

Legacy No MS005




60 October 2011

010787 User acceptance testing

Registries shall be able to perform user acceptance testing for system components that will be used by non-registry staff before changes are placed into production.

Legacy No MS007



010788 Administration support hours of operation

Registries shall provide system administration support during week day office hours from 9:00 to 17:00 (public holidays excluded).

Additional Notes The cost for this is anticipated to be two full-time Registries Administrator with one additional part-time or on-demand resource to cater for sickness and other unscheduled leave of absence.



010789 Development and test environments

Registries IT infrastructure shall provide the ability to configure development and test environments within one working day of notification.

Rationale To enable the most effective sharing of resources in data centre(s) the environment(s) should be able to be virtualised.

Additional Notes The test environment does not need to mirror the CPU or memory capacity of the production environment(s) unless load testing is required.



010790 Number of development licenses

Registries shall make provision for development software licenses. The number of development licenses will depend on the arrangements/ resources/ time-frames for development, maintenance and support.

Additional Notes Number to be confirmed.



nehta Requirements

October 2011 61

010791 Training environments

Registries’ IT infrastructure shall provide the ability to configure a training environment within five working days of notification.

Additional Notes The training environment does not need to mirror the CPU or memory capacity of the production environment.

In some instances the training data repositories need to contain all records of the database. Disk capacity will therefore need to be the same as in the production environment(s).



3.3.6 Security

010552 Review security and access requirements against standards

Registries shall review their security and access requirements annually against AS ISO 27799 Information security management in health using ISO/IEC 27002 and emerging frameworks such as the National E-Health Security and Access Framework (currently in development).

Additional Notes AS ISO 27799 Information security management in health using ISO/IEC 27002 specifies guidance on for healthcare organisations and other custodians of personal health information on how best to protect the confidentiality, integrity and availability of such information.

Legacy No R110



3.3.6.1 Audit

010548 Inclusion of audit processes in registry design

Registries shall have audit processes inherent in their design. These will be automated where possible.

Legacy No R086




62 October 2011

010746 Audit trails to record data linkage details

Registries shall record details of data export (for the purpose of data linkage) in comprehensive audit trails.




010750 Ability to trace export of data

When information is exported for research or other purposes registries shall be able to trace when the information has been exported in the system (audit trail).




010549 Audit trails will track users and activity

Registry audit trails shall track all instances of record creation, reading, updating and deletion and recorded who undertook the activity was undertaken (e.g. who entered data from where; what records were viewed, altered; what reports were viewed/generated/issued).

Legacy No R087



010755 Data extraction to be audited

Registries shall only support data extraction of identifiable information via the user interface, to enable auditing.

Legacy No R116; 116d



nehta Requirements

October 2011 63

010802 Audit log to record data export and recipient details

Registries shall have an audit log that records what records and fields were exported, the recipient of the exported data, when the data were received, and the authorisation code.

Legacy No R116; 116e



3.3.6.2 Access

010536 Use secure access controls

Registries must use secure access controls to protect the privacy of participants and restrict access to those who are authorised.




Related Items Req # 010540. Local user registration (Related)

010544 Authenticate identity at each session

Registries shall require users to authenticate their identity at the beginning of a session.

Legacy No R084



010538 Individuals to authenticate themselves separately

Registries shall ensure that individual users authenticate themselves separately to enable audit trails to identify each user who has interacted with the system.

Additional Notes

Legacy No R098




64 October 2011

010550 Log failed authentication attempts

Registries shall log failed authentication attempts.

Legacy No R108



010799 Terminate inactive sessions

Registries shall terminate inactive sessions after a defined period of time.

Rationale To prevent access by unauthorised users.



010553 Management of multiple identifiers for an individual

Registries shall support the ability of an individual user to be assigned with different system privileges in different organisational settings.

Rationale Individual users may fulfil different organisational roles within different institutions or organisations. Their user privileges should be able to be assigned differently in each setting to reflect that access required in relation to the role they undertake in each setting.

Legacy No R015



010599 Different permissions for subsets of data

Registries shall support the setting and use of different permissions for different uses of subsets of registry data.

Legacy No R126



nehta Requirements

October 2011 65

010537 Use of authentication mechanisms across registries

Registries shall use consistent authentication mechanisms to ensure that the level of authentication required of claimed user identity is consistent with the level of access that will become available to the user.

Rationale Ability to set levels of authentication.

Legacy No R076



010792 Unambiguous user identifier

Registries shall accurately capture and record a user's identity through the assignment of an unambiguous user identifier.

Rationale Registries need to record the name/identity of a user, not just the ID that they use to log in.



010539 Selection of own passwords or pin codes

Registries shall allow individual users to select their own passwords or pin codes

Legacy No R077



010793 Users can have password reset

Registries shall provide users with the ability to have their password reset if it has been forgotten.




66 October 2011

010794 Encrypt passwords

Registries shall ensure that passwords are stored in an encrypted form.

Rationale To reduce the potential for unauthorised access.



010795 Strong password policies

Registries shall employ strong password policies.



010796 Apply expiry dates to user access

Registries shall enable expiry dates to be applied to user access.

Rationale To ensure that access for users does not extend beyond their period of employment in a role or period during which their access to the registry is required as part of the performance of their role.



010797 Password changes

Registries shall define the period after which user passwords must be changed.



nehta Requirements

October 2011 67

010540 Local user registration

Registries shall allow for user registration to be undertaken using a distributed approach across participating institutions. Local system administrators shall be able to allocate passwords and system privileges to users within their institution.

Additional Notes

Legacy No R078



Related Items Req # 010536. Use secure access controls (Related)

010798 Expiration of user accounts

Registries shall ensure that user accounts are reviewed by system administrators after a pre-defined period and extended if further access is required.

Rationale To ensure that access to the system is tightly controlled and that users rights for those who no longer require access are removed.



010541 Agree to terms of registry participation

Registries shall require users to agree to the terms and conditions of participating in a registry when they first authenticate themself to the system, when their password is reset and when Terms and Conditions of participation change.

Legacy No R079




68 October 2011

010803 Lock account after unsuccessful authentication attempts

Registries shall lock a user account for a defined period of time once a specified limited number of unsuccessful authentication attempts have been made by a user to access the system.

Rationale To prevent unauthorised access to the system.



010590 Use of NeAF

Registries shall use the National E-Authentication Framework in registry system design to determine an appropriate level of authentication.

Legacy No R100



010720 Automatic logoff after inactivity

Users shall be automatically logged off after a pre-set period of inactivity.



010551 IP address monitoring

Registries shall automatically identify equipment as a means to authenticate connections from specific locations and equipment.

Additional Notes May use, for example, Google Analytics

Legacy No R109



nehta Requirements

October 2011 69

010800 Define period of inactivity

Registries shall enable local system administrators to define the period of inactivity that can be permitted prior to terminating an inactive session.



3.3.6.3 Communications

010524 Receive encrypted records when importing data

Registries should have the ability to accept encrypted records when importing data.

Legacy No R103



010747 Use secure electronic transfer

Registries must use secure electronic transfer and electronic messaging systems to protect the privacy of participant information when data are in transit.

Additional Notes




010748 Ability to receive secure electronic messages

Registries shall be able to receive messages and information received through secure electronic messaging and secure electronic transfers.

Legacy No R090



011168 Use of virus scanning

Registries shall use virus scanning software to allow prevention, detection and/or removal the introduction of damaging or disruptive malware to the system.




70 October 2011

3.3.7 Legal

010724 Hosting location

Registries shall be hosted in Australia and be subject to Australian law in order to fully comply with the Privacy Act (Cth) 1988.



010778 Information and records management standards

Registries shall comply with the Australian and international standard for records management.

Additional Notes The Australian and international standard for records management, AS ISO 15489, provides guidance on creating records policies, procedures, systems and processes to support the management of records in all formats. It is widely used in Australia and internationally in both private and public organisations.

The National Archives of Australia endorses AS ISO 15489 for use in the Australian Government. This standard provides the basis for the entire Archives’ records management standards, policies and guidelines.



Date post:	27-May-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Requirements Specification (CQR1200) Consultation Draft · The Architecture Development Programme...

Documents