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.
nehta Table of contents
October 2011 iii
This page is intentionally left blank
National Clinical Quality Registries Requirements Specification (CQR1200)
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:
National Clinical Quality Registries Requirements Specification (CQR1200)
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].
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.
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
National Clinical Quality Registries Requirements Specification (CQR1200)
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
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
nehta Requirements
October 2011 13
010598 Right to opt-out
Registries shall support the right of patients to opt-out.
Legacy No R125
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
010756 Informed consent
Registries shall provide participants (eligible population) with the option not to participate.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
010616 Common data collection approaches
Registries shall collect data using common and systematic approaches
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
010719 Publication of metadata, data dictionaries and indicators
Registries shall publish metadata, data dictionaries and indicators to a publicly available website.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
14 October 2011
010710 Identifying information to support registry purpose
Registries shall collect sufficient patient identifying information to support the registry's stated purpose.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
010621 Timely capture of data
Registries shall capture data as close as possible to the time and place of care.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
010660 Monitor quality in accordance with plans
Registries shall monitor the completeness and accuracy of the data collected in accordance with quality assurance plans.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Legacy No R116; R116a
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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
Type Business Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
010622 Trained data collectors
Registries shall use appropriately trained data collectors to capture data.
Priority Medium Release 1.0 Status Closed
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.
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
18 October 2011
010715 Specific case definition
Registries shall only collect information related to a specific case definition.
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
3.2.1.2 Publish eligibility
010820 Publish eligibility criteria
Registries shall publish patient eligibility criteria on a publicly accessible website
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010763 Allow multiple episodes to be recorded
Registries shall allow data relating to multiple episodes for a single patient to be imported.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010637 Alter records via data import
Registries shall be able to use automated data import processes to append, modify, or discard patient records.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010641 Mark mandatory fields
Registries shall be able to identify which fields within a record are mandatory.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010646 Data record rejection
In the case that records are rejected, a reason can be recorded against it.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Type Functional Optionality Mandatory
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
Priority Low Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010520 Barcode Scanning
Registries shall facilitate barcode scanning of patient identification labels on paper forms.
Legacy No R102
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010759 Download printable forms
Registries shall enable users to download printable forms to aid manual data collection.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010817 Offline forms
Users shall be able to download offline forms for data entry.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
28 October 2011
010519 OCR in scanning
The registry should facilitate OCR in scanning of paper forms.
Legacy No R101
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010758 Storage of paper-based data sources
Registries shall be able to store electronic copies of paper-based data collection forms.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010816 Download follow-up forms
Registries shall enable users to download printable or offline forms to aid the collection of follow-up information.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
30 October 2011
010682 Authorised users can unlock records
Registries shall enable authorised users to unlock records.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Low Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010558 Probabilistic matching
Registries shall support probabilistic matching of identifying information against existing registry data.
Legacy No R111
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
010661 Audit for accuracy against source
Registries shall check data accuracy in a sample of cases using audits against source records.
Priority Medium Release 1.0 Status Closed
Type Business Optionality Mandatory
010821 Double entry to check accuracy
Users shall be able to double enter patient information to check the accuracy of data entry.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Low Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010571 Access to restricted reports
Registries shall implement business rules and special permissions relating to access for restricted reports.
Legacy No R115
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
nehta Requirements
October 2011 37
010569 Clinical and epidemiological reporting
Registries shall support clinical and epidemiological reporting
Legacy No R113
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Legacy No R020; R020a
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
nehta Requirements
October 2011 39
010753 Encrypt exported identifiable information
Registries must encrypt identifiable information at the point of export.
Legacy No R116
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010696 Compatibility of data extracts with statistical packages
Registries shall support secure extract of data in formats compatible with major statistical packages.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010691 Use report parameters to generate ad hoc reports
Registry users shall enter information into pre-defined report parameters to generate ad hoc reports.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010775 Time variant data
Registries shall maintain data in such a way that enables the time period of data capture to be identified.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
010586 Date stamp business rules
Registries shall have the ability to date stamp Business Rules.
Legacy No R117
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010648 Use of touch screens
Registries shall support the use of touch screens.
Legacy No UA003
Priority Low Release 1.0 Status Closed
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
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
48 October 2011
010653 Training expectations
Registry users (participating data providers) performing data entry functions shall only require basic training.
Legacy No UA009
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Optional
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Optional
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010594 Disaster recovery procedures and facilities
Registries shall develop appropriate disaster recovery procedures and associated infrastructure (e.g. failover and redundancy)
Legacy No R014
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010673 Loss of data following disaster recovery
Registries shall tolerate the loss of not more than one hour of data loss following disaster recovery.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010695 Continuation through validity checks
Registries shall save data that does not meet business validation rules.
Legacy No OP006
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
Related Items Req # 010813. Flag to indicate data that do not meet business validation rules (Child)
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority Medium Release 1.0 Status Closed
Type Functional Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Optional
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010608 Consistent interface and integration design.
The design of interfaces and integration shall be consistent across registries.
Legacy No R031
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010771 Health documents exchange
Registries shall use the Clinical Document Architecture (CDA) to encode and structure clinical documents for exchange.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010772 Use of standard data exchange mechanisms
Registries shall adopt agreed Australian standards for healthcare information interoperability.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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).
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Legacy No R019; R019b
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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).
Legacy No R020; R020b
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Legacy No R090; R090a
Priority High Release 1.0 Status Closed
Type Business Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
64 October 2011
010550 Log failed authentication attempts
Registries shall log failed authentication attempts.
Legacy No R108
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010799 Terminate inactive sessions
Registries shall terminate inactive sessions after a defined period of time.
Rationale To prevent access by unauthorised users.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010539 Selection of own passwords or pin codes
Registries shall allow individual users to select their own passwords or pin codes
Legacy No R077
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010793 Users can have password reset
Registries shall provide users with the ability to have their password reset if it has been forgotten.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010795 Strong password policies
Registries shall employ strong password policies.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
010797 Password changes
Registries shall define the period after which user passwords must be changed.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Optional
010720 Automatic logoff after inactivity
Users shall be automatically logged off after a pre-set period of inactivity.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Low Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Legacy No R090; R090b
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
National Clinical Quality Registries Requirements Specification (CQR1200)
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.
Priority High Release 1.0 Status Closed
Type Non-Function Optionality Mandatory
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.
Priority Medium Release 1.0 Status Closed
Type Non-Function Optionality Mandatory