output based specification

National Genetics Reference Laboratory (NGRL) Manchester

NHS Genetic Service Information Systems

Output Based Specification (OBS)

Document No. GEN-3-006

Version 1.2

8 September 2005

Genetics Information Systems OBS

Version 1.2, 8 September 2005 of 104

Document Details Prepared By IT Perspectives Ltd, Simon McCusker, Simon Heathfield. Version 1.2, 8 September 2005 Pages 104 Filename ITP-GEN3-006-OBSv1-2.doc Saved 08/09/2005 14:42:00 Printed 24/11/2005 10:11 AM History Date Name Version Description.

11/02/2005 SM 0.1 Created. 17/05/2005 SM/RE 0.2 Review. 19/05/2005 SM/RJ 0.3 Review. 20/05/2005 SM 0.4 First complete draft. 27/05/2005 SM 0.5 Updates from initial comments and draft release. 29/05/2005 SM 0.6 Further updates. 29/07/2005 SH 1.0 Updates following community consultation. 19/08/2005 SH 1.1 Minor updates following QA.

8/09/2005 AD 1.2 Minor amendments following sign-off



Contents

Introduction ............................................................................................................. 5 Section 1-1 Background..........................................................................................................6

1.1.2 Scope......................................................................................................................7 1.1.3 What is an OBS? ......................................................................................................7 1.1.4 Assumptions and Notes.............................................................................................7 1.1.5 About this Document ................................................................................................8 1.1.6 Benefits and Risks ....................................................................................................8 1.1.7 Acknowledgements...................................................................................................9

Section 1-2 NHS Genetic Services..........................................................................................10 1.2.1 Introduction...........................................................................................................10 1.2.2 Genetic Disorders ...................................................................................................10 1.2.3 Core Genetic Service ..............................................................................................10 1.2.4 Elements of the Genetics Service .............................................................................11 1.2.5 Regional Genetic Centres ........................................................................................12 1.2.6 Unique Requirements of Genetic Services .................................................................13

Key Issues Arising in the Consultation................................................................... 16 Section 1-3 Introduction .......................................................................................................17

1.3.2 Pedigree Support ...................................................................................................17 1.3.3 Regional and National Integrated Records ................................................................17 1.3.4 Confidentiality and Consent.....................................................................................18 1.3.5 Long Term Relationships with Patients .....................................................................19 1.3.6 National Care Records ............................................................................................19 1.3.7 Laboratory Network Management ............................................................................20 1.3.8 Sample and Request Tracking and Tracing ...............................................................23 1.3.9 High Throughput Testing ........................................................................................24 1.3.10 Cross-Disciplinary Working ......................................................................................25

The National Context.............................................................................................. 27 Section 1-4 The Genetics White Paper ...................................................................................28

1.4.1 Introduction...........................................................................................................28 1.4.2 General Requirements from the White Paper ............................................................28 1.4.3 Laboratory System Requirements ............................................................................29 1.4.4 Decision Support ....................................................................................................29 1.4.5 Practical Implications of the White Paper..................................................................29



Section 1-5 International Programmes ...................................................................................31 1.5.1 Introduction...........................................................................................................31 1.5.2 The English NHS Connecting For Health (NCfH) ........................................................31 1.5.3 The Welsh NHS – Informing Healthcare....................................................................34 1.5.4 NHS Scotland - Ehealth/IM&T Strategy....................................................................36 1.5.5 NHS Northern Ireland – HPSS ICT Strategy ..............................................................37 1.5.6 Implications for Genetic Systems .............................................................................37

Clinical Genetics ..................................................................................................... 41 Section 1-6 An Overview of Clinical Genetics ..........................................................................42

1.6.1 Introduction...........................................................................................................42 1.6.2 Clinical Genetics Workflow ......................................................................................44

Genetic Laboratory Services................................................................................... 51 Section 1-7 An Overview of Laboratory Services .....................................................................52

1.7.1 Introduction...........................................................................................................52 1.7.2 Cytogenetic Testing................................................................................................52 1.7.3 Molecular Genetic Testing .......................................................................................53 1.7.4 Laboratory Integration............................................................................................53 1.7.5 Genetics Laboratory Workflow .................................................................................54

Section 1-8 Entities within Genetic Laboratory Information Systems .........................................65 Requirements ......................................................................................................... 69

Section 1-9 Introduction .......................................................................................................70 Section 1-10 Common Requirements ...................................................................................71 Section 1-11 Requirements of Clinical Genetics .....................................................................78 Section 1-12 Requirements of Laboratory Genetics................................................................88

Conclusions and Recommendations....................................................................... 99 Section 1-13 Conclusion.................................................................................................... 100

1.13.2 Recommendations................................................................................................ 100 Appendix A : Glossary........................................................................................... 103



Introduction



Section 1-1 Background

1 In June 2003, the Department of Health published a White Paper titled "Our Inheritance, Our Future" which outlined a program of reform and investment in the provision of genetic services in England:

“… the Department of Health will invest up to £1 million over three years in IT for genetics laboratories in the Genetic Testing Network. This will enable better handling of work and communications within and between participating laboratories. These new systems will be compatible with the Government's wider investment programme to modernise NHS IT systems and introduce electronic patient records.” [Our Inheritance, Our Future - 2.38].

2 The White Paper does not define how the £1 million for IT systems in Genetics will be spent. It therefore presents an opportunity for the genetics community to define its common requirements for IT systems. To support this, the NRGL (Manchester) commissioned a piece of work titled 'Analysis and Options Appraisal for Information Management of Systems in Genetics'. The resulting report identified the production on an Output Based Specification (OBS) as an important first step towards achieving the aims of the White Paper.

3 After a competitive tender the consultants IT Perspectives Ltd. were appointed to carry out the production of the OBS. The project was managed by the NGRL (Manchester) on behalf of the Department of Health. Work on the OBS commenced in January 2005 and completed in July 2005. It represents approximately 60 days work.

4 The OBS defines a core set of information system requirements that will allow the genetic community to improve information support within genetic centres and support better network operation at a regional and national level. The OBS is intended to:

Allow each regional genetics centre to procure against a common set of requirements that ensure an appropriate core set of functionality is achieved.

Allow effective communication within and between the regional centres.

Allow effective communication with the wider NHS.

Conform to the aspirations of the NHS national programmes for IT improvement and the genetics White Paper.

Avoid duplicated system specification effort within regional centres.

Combine the expertise of the whole genetic community.

5 The work focuses on activities of the NHS regional genetics centres (RGC) and includes Clinical Genetics, Molecular Genetics Laboratories and Cytogenetic Laboratories.



1.1.2 Scope

6 The OBS is intended to cover the core activities of the NHS Regional Genetic Centres as defined by the survey (A review of information systems in English Regional Genetic Services, IT Perspectives, April 20041) and Specialised Services National Definitions Set – Medical Genetic Services (all ages) – Definition No. 20.

7 The work includes:

Clinical Genetics.

Laboratory Genetics (including Cytogenetics and Molecular Genetics).

8 It excludes biochemical genetics or any genetic activity in specialist departments (for example cancer services).

1.1.3 What is an OBS?

9 OBS are commonly employed within NHS system procurements to provide a clear description of need, two definitions are included below:

“… OBS describes the output requirements for planned investments in new systems and/or services plus any constraints that apply to the proposed solution(s), such as the need to meet national or local standards and the need to interface with existing systems.” [NHS Purchasing and Supply Agency (PASA)]

“… an output based specification that focuses on what you want, not how to provide it” [Office of Government Commerce (OGC)]

10 So, an OBS is a requirements document that focuses on the required functionality of a system but does not define how the functionality is to be achieved.

1.1.4 Assumptions and Notes

11 Use of the word ‘system’ in the OBS does not assume a single monolithic application. A system may be composed of many separate components.

12 A requirement of the OBS was to challenge current thinking with ambitious requirements.

13 The OBS attempts to present UK wide scope and includes descriptions of all home countries plans for IT improvements. However the pace of the English NHS Connecting for Health (NCfH) programme and the limited scope of the White Paper funding has lead to a focus on the implications and integration requirements of the English National Programme for IT (NPfIT) managed by NHS Connecting for Health (NCfH).

14 The OBS includes sections about the user view and access to genetic services, however the scope of the OBS excludes the ‘mainstreaming’ of genetic services, for example looking for genetic features in disease and taking pharmacogenetic factors into account in prescribing. 1 Available from www.ngrl.org.uk.



1.1.5 About this Document

15 This document forms the OBS for information systems employed in clinical and laboratory genetic services in the UK. It is intended for expansion and localisation for support of a coherent approach to system procurement in order to meet the aspirations of the genetics community and the genetics White Paper as well as playing a full role in the national programmes for improvements to NHS IT systems (e.g. NHS Connecting for Health in England).

16 The document consists of the following sections:

Chapter 1 introduces the OBS development project and sets it in context by providing an overview of genetic services.

Chapter 2 describes the key issues arising from the consultation, these were the issues that were repeatedly discussed and are receiving the most attention in the genetics community. Most of these have been introduced by the targets set by the genetics White Paper and the pressure to achieve network operation introduced through the aspirations of the genetics community and the national programmes for IT improvement.

Chapter 3 discusses the major pressures for change affecting the genetics community, these are:

The genetics White Paper.

The national programmes for IT improvement in England, Wales and Northern Ireland.

Chapter 4 describes the activities of Clinical Genetics through a generalised high level workflow.

Chapter 5 describes the activities of Laboratory Genetics through a generalised high level workflow.

Chapter 6 presents the requirements arising from the consultation, it is split into three areas:

Common requirements, the general requirements of systems employed in clinical and laboratory genetics.

Requirements of clinical genetics.

Requirements of laboratory genetics including both molecular genetics and cytogenetics.

Chapter 7 concludes the OBS with some recommendations intended to move towards a more coherent approach to genetic information systems able to communicate effectively within the genetic service and with its users.

1.1.6 Benefits and Risks

17 System procurement based on this OBS would be expected to realise the following benefits:

Core functionality to meet common requirements based on the combined expertise of the Genetics community.

Minimisation of duplication of effort in system specification.



Independent specification & procurement of clinical and laboratory systems to common standards.

Core functionality to support English Connecting for Health 'National Spine Services’:

Choose and Book.

Care Records Service.

Personal Demographics Service.

Secondary Uses Service.

Transaction and Messaging Service.

Access Control Framework.

Better and consistently derived information for workload and quality management.

Standard integration support (messaging/coding etc) to facilitate communications within and between Regional Genetics Centres.

18 Standard integration support (messaging/coding etc) to facilitate communications with the wider NHS, including cross-disciplinary support.

19 Consistent approach to integration of new technologies, e.g. support for high throughput testing facilities.

20 Ignoring the OBS could introduce risks, for example:

Sidelining of Genetics through non-interoperability with the wider NHS.

Subsumption of Genetics information systems into integrated Pathology solutions.

Inefficient or ineffective implementation of Genetics Network goals such as Track & Trace.

1.1.7 Acknowledgements

21 This work could not have been completed without the enthusiastic help of all in the genetics community and some outside it (e.g. NCfH). Thanks to Alan Donaldson, Alison Hill, Amanda Collins, Andrew Clifford, Andrew Devereau, Andrew Marsh, Andrew Wallace, Anne Gardner, Beki Ruban, Carol Chu, Cathrine Williams, Chris Mattocks, Cyril Chapman, David Coburn, David Gokhale, Dianne Kennard, Heather Develin, Jeremy Thorp, John Barber, John Emslie, Jonathan Berg, Kathryn Williams, Louise Anderson, Louise Newport, Lucy Jenkins, Maggie Williams, Mark McGowan, Mike Bainbridge, Mike Griffiths, Noel Hannan, Peter Dyke, Richard Holt, Richard Renshaw, Rick Jones, Rob Elles, Rob Morgan, Sally Jeffries, Sally Stanley, Simon Withey, Stan Woods, Steve Elwood, Steve Evans, Teresa Davies, Tony Young, Yvonne Wallis, Eileen Collier, Helen Stewart, John Crolla and all that I met whose names I missed.



Section 1-2 NHS Genetic Services

1.2.1 Introduction

22 This section summarises the National Specialised Service Definition of Genetic Services (no. 20). The summary includes only the elements of the service within the scope of the OBS.

1.2.2 Genetic Disorders

23 Genetic disorders include:

Chromosomal abnormalities that cause birth defects, learning difficulties, reproductive problems - e.g. Down’s syndrome, Edwards’ syndrome, chromosome translocations.

Single gene disorders such as cystic fibrosis, muscular dystrophy, Huntington disease and inherited metabolic disorders.

Familial cancer and cancer-prone syndromes such as inherited breast or colorectal cancer.

Birth defects with a genetic component such as neural tube defects and cleft lip and palate.

Acquired genetic disorders such as haematological malignancies and tumours.

24 In addition a large number of individuals with birth defects and/or learning disabilities are referred and investigated for genetic factors. Individuals identified through childhood or pregnancy screening programmes also require genetic services. In the future, as the genetic contribution to common later onset disorders such as diabetes and coronary heart disease is identified, services may be required for those at high risk. Testing for genetic factors, which affect drug prescribing (pharmacogenetics), will also become an increasingly important activity.

1.2.3 Core Genetic Service

25 A core genetic service is defined as:

26 An integrated clinical and laboratory service, provided for those with, or concerned about, a disorder with a significant genetic component, and their families (this includes inherited and sporadic genetic disorders) offering:

Accurate clinical and genetic laboratory diagnosis.

Risk estimation (interpretative role).

Genetic counselling (including pre and post predictive testing).



Accessible information for families/other health professionals and patient support groups (written and spoken).

Support to individuals and families (e.g. in decision making about future pregnancies).

Prevention of a disorder or complications including family follow-up (e.g. anticipatory care, pre natal care and testing).

Expert advice to other health professionals and commissioners.

Education and training for other health professionals including those providing genetic counselling within other specialised services (see below) and for undergraduate and postgraduate students.

Participation in research and clinical audit.

A family based approach where required.

Maintenance of confidential family records.

Maintenance of a DNA storage service.

1.2.4 Elements of the Genetics Service

1.2.4.1 Clinical Genetics 27 This is the speciality which provides a diagnostic service and genetic counselling for

individuals or families with, or at risk of, conditions which may have a genetic basis.

28 The services also contribute to direct patient care running clinics over extended periods of time in support of, e.g. Turner Syndrome, Huntington Disease. In some instances such clinics are run jointly with other specialities, e.g. endocrinology, metabolic medicine.

1.2.4.2 Laboratory Genetics 29 Laboratory Genetics has two specialisms: Cytogenetics and Molecular Genetics which carry

out tests including:

Diagnostic testing used to diagnose or rule out a specific genetic or chromosomal condition. In many cases, genetic testing is used to confirm a diagnosis when a particular condition is suspected based on physical signs and symptoms. Diagnostic testing can be performed at any time during a person's life, but is not available for all genes or all genetic conditions. The results of a diagnostic test can influence a person's choices about health care and the management of the disorder.

Carrier testing used to identify people who carry one copy of a gene mutation that, when present in two copies, causes a genetic disorder. This type of testing is offered to individuals who have a family history of a genetic disorder and to people in ethnic groups with an increased risk of specific genetic conditions. If both parents are tested, the test can provide information about a couple's risk of having a child with a genetic condition.

Prenatal testing used to detect changes in a foetus’s genes or chromosomes before birth. This type of testing is offered to couples with an increased risk of having a baby with a genetic or chromosomal disorder. In some cases, prenatal testing can lessen a couple's uncertainty or help them make decisions about a pregnancy. It cannot identify all possible inherited disorders and birth defects, however.



Predictive and presymptomatic testing, used to detect gene mutations associated with disorders that appear after birth, often later in life. These tests can be helpful to people who have a family member with a genetic disorder, but who have no features of the disorder themselves at the time of testing. Predictive testing can identify mutations that increase a person's risk of developing disorders with a genetic basis, such as certain types of cancer. Presymptomatic testing can determine whether a person will develop a genetic disorder, such as hemochromatosis (an iron overload disorder), before any signs or symptoms appear. The results of predictive and presymptomatic testing can provide information about a person’s risk of developing a specific disorder and help with making decisions about medical care.

1.2.4.3 Cytogenetics 30 This includes the laboratory services for diagnosis of chromosomal abnormalities, both

congenital and acquired, that can be detected using high resolution microscopy, molecular cytogenetic techniques, e.g. Fluorescent In-situ Hybridisation (FISH) or other specialised procedures, e.g. Comparative Genomic Hybridisation (CGH).

1.2.4.4 Molecular Genetics 31 Testing for inherited disorders, or post symptomatic diagnosis of genetic conditions that

involves the analysis of DNA, either through linkage analysis, sequencing, or one of several methods of mutation detection.

1.2.5 Regional Genetic Centres

32 Genetic services in the UK are provided through centres that draw together the clinical and laboratory services. However, the local configuration of services varies greatly. In some centres the clinical and laboratory services are very closely associated, sharing common premises, management structure, operational methods and information systems. In others different sections run as entirely independent entities, sometimes in different cities. In some cases the laboratory services run independent molecular and cytogenetic services.

1.2.5.2 Information Systems in Genetic Services 33 The information systems in use in regional genetic centres fall into two categories (mirroring

the high level elements of Definition 20). The systems are:

Clinical Genetic Systems – used by clinical geneticists, genetic counsellors, family register staff and administrative staff to manage the work of the clinical genetics centre. For example manage clinics and capture demographic, pedigree and clinical information about patients.

Laboratory Information Systems used in Molecular Genetics and Cytogenetic Laboratories to manage the information and workflow involved in genetic testing.

34 Where genetic services are integrated they often share a common information system, where services are partitioned they often procure and manage systems independently. The different configurations are classified in Table 1.



Table 1. Information System Configuration

Class Description Fully integrated A Single system with a shared datastore, for example clinical,

molecular and cytogenetics all share a common application and a common underlying database.

Semi integrated A Single system with distinct datastores (e.g. separate clinical and laboratory datastore), for example clinical, molecular and cytogenetics use the same system, but clinical services have a separate database.

Non integrated Distinct systems with distinct datastores (sometime separate clinical, molecular and cytogenetic systems). For example each service has dissimilar applications and no shared datastores.

1.2.6 Unique Requirements of Genetic Services

36 The survey of genetic information systems identified the following areas to be either unique or of special importance to genetic services. It is these areas that make mainstream clinical or laboratory systems unsuitable for use in genetic services.

1.2.6.2 Family Relationships - Pedigree 37 If there is one thing that sets genetics apart from other specialities it is the concern with

family relationships. It is fundamental to clinical and molecular genetics and important in cytogenetics. In many cases tests are attempting to establish a probability that an individual will suffer from a condition by interpreting tests carried out on their relatives.

38 Records must provide a means of capturing family relationships (pedigree) and analysis and reporting must provide means of visualising, managing and analysing the relationships. There are a number of commercial computer applications routinely used in genetic centres to support this, for example Progeny, Cyrillic and BRACPRO.

1.2.6.3 Long Term Relations with Patients and Families 39 Genetic conditions belong to families not individuals, thus once identified consultations with

the families may continue through the generations. In addition genetic techniques are constantly developing and thus new tests may be carried out on DNA samples held in laboratories and new treatments may be applied to conditions identified long ago. This means that the genetic centres must retain information and genetic material of past generations for possible retesting in order to inform present generations.

40 Genetic systems must support long-term relationships with families. They must ensure that recommended intervals between surveillance appointments are respected and that patients are recalled when counselling, a retest or a treatment may be appropriate.

1.2.6.4 Close Ties with Research 41 Genetics is a fast developing speciality. Many of the tests have only recently emerged from

the research community. Much of the instrumentation used in molecular genetics has been developed as part of the human genome project. NHS genetic services must have two-way communications with research establishments, and they must:



Adopt and adapt research techniques to provide practical and efficient tests and treatments for genetic conditions.

Contribute to research regarding the conditions and progress of patients and families in their care (for example tracking progress of disease compared with genetic projection).

42 Thus genetic information systems must:

Be able to define and collect datasets of anonymised and/or pseudonymised information across the genetic network.

Support coded clinical details (e.g. SNOMED-CT or OMIM).

Support result submission to central databases (e.g. Winter-Baraitser Dysmorphology Database2 - WBDD, and the Diagnostic Mutation Database Project – DmuDB).

1.2.6.5 Information Governance 43 The regional genetic centres are very conscious of the sensitivity of the information they hold

and respect the wishes of patients in sharing that information. The introduction of computer based information systems in the NHS has made this an important topic throughout the organisation. Genetic conditions have some special issues, the information is particularly sensitive and it is relevant to whole families not individuals. Genetic centres must:

Hold information securely.

Gain consent for the use and sharing of information and samples, this must include:

Retaining DNA samples (Human Tissue Act 2004).

Passing DNA to other service centres.

Passing results when other family members are tested.

Research use.

44 Clinical systems must provide support for taking, managing and exporting a patient's consent settings. All systems must track and automatically limit the use of information consistent with the wishes expressed by the patient.

1.2.6.6 High Levels of Analysis and Interpretation of Test Results 45 Genetic testing requires a great deal of analysis and interpretation. The results of numerous

tests may need to be combined. The test reports tend to be long and contain a great deal of free text and diagrams. Some labs include tabular details of individual test results and an interpretation; some labs include only the interpretation.

46 Genetic scientists and clinicians use applications (decision support, expert systems) that can aid the interpretation process, for example karyotype analysis and Bayesian analysis tools. Molecular genetic reports routinely contain pedigree diagrams.

47 Genetic information systems must support the creation of complex reports containing text, pictures and diagrams. The reports may combine multiple pre-configured elements (e.g. standard paragraphs). Scientists creating the reports may use external decision support systems that may benefit from some level of integration (e.g. exchanging datasets, mutation databases and published articles).

2 Previously Known as the London Dysmorphology Database.



1.2.6.7 Very Specialised Tests 48 Genetic tests can be very complex. Molecular testing in particular comprises multiple subtests

and the subtests may use distinct techniques. The result of one subtest may influence the test path, for example it may end the test (e.g. with an identified condition) or suggest an alternative test path (e.g. a more specialised test).

49 The complexity of tests means that genetic test periods can be extended and the test period may span billing periods (the genetics White Paper demands much shorter test times however the complexity means that test periods are likely to remain extended where new tests are introduced).

50 Specialised tests mean that the number of tests offered is high and the number of samples per test low (laboratories reported that these specialised tests were their highest area of growth). When high volume equipment is employed the configuration of samples in plates can be complex and change through the test pathway (e.g. DNA extraction, primary processing and test). In addition the tests can produce large volumes of information (e.g. multiple exon subtest results). To minimise test time and potential for error comprehensive worksheet support and data exchange with equipment is invaluable.

51 Tracking of long complex tests should be supported by frequent check-points within the information system.



Key Issues Arising in the Consultation



Section 1-3 Introduction

52 The issues identified in this section are those repeatedly raised during the consultation. They are the issues associated with information systems, which are causing most concern and effort within the genetics community. The issues raised in clinical and laboratory genetics are presented together.

1.3.2 Pedigree Support

53 The focus on family sets genetics apart from other specialisms. It is vital that genetic systems provide full and rich support for compiling, visualising, managing and analysing comprehensive pedigree information. This means systems must:

Provide flexible relationship tables able to support complex relationships to include:

Family identifier.

Mother and Father.

Unborn children.

Relations through existing and planned pregnancies.

Surrogacy.

Provide or closely integrate with pedigree visualisation applications.

Updates to data fields or relations should be synchronised across different views, for example changes made to pedigree diagrams should be reflected in the patient records and vice-versa.

Integrate with family relationship analysis programmes, for example BRCAPRO for assessing the probability that an individual carries a mutation of the BRCA1 and BRCA2 genes.

Support family liaison, for example family appointments at clinics and family correspondence.

Support administrative and clinical information sets at the family level.

54 In summary it is vital that the concept of family underlies the entire genetics information system.

1.3.3 Regional and National Integrated Records

55 Genetic specialists often manage multi-disciplinary care and use information from many areas outside the genetics centre (e.g. x-rays, ECGs and many types of investigation reports). Systems should provide access to information from other specialities where it is available, for example integration with:

Electronic Patient Records (EPR).

Requesting and Order Communications.



Results Reporting

Picture Archive and Communication Systems (PACS).

Screening systems.

56 Genetic centres have regional catchment areas, thus where possible, integration must not be restricted to local hospital systems but should be at the regional or national level.

57 Genetic specialists refer to many regional, national and international resources to support patient care, for example:

Cancer Registries.

Disorder specific databases (e.g. Muscular Dystrophy and Cleft Group).

Links to standard genetic code sets e.g. Online Mendelian Inheritance in Man (OMIM), Winter-Baraitser Dysmorphology Database3 (WBDD).

58 Systems should provide the ability to link and interact with external databases and registries to (a) access information, (b) update resources with new information (e.g. new mutations).

59 Geographic family distribution means that investigations may link family members registered with different regional genetic centres. Systems should allow detailed information to be shared and exchanged within the limitations of consent.

60 To come into line with other NHS services, it is likely that genetic investigations will require support for external QA (e.g. NEQAS) activity. In biochemistry this is increasingly supported through electronic information exchange. In Genetics there will be need for image analysis support and sharing. This will require the sharing of pseudonymised patient and family information which will need handling like real patients through the workflow. It will become more important as the service moves to automated/high volume techniques.

1.3.4 Confidentiality and Consent

61 Changes in technology, attitudes and legislation have brought issues around confidentiality and consent to the fore, genetics collects and generates very sensitive information about individuals and families. The information can have serious practical implications, for example access to insurance. Genetic systems must take a robust and systematic approach to confidentiality and consent. Confidentiality is implemented through a number of routes including (a) physical security of resources, for example computer system and network security and physical area access control, and (b) robust security policies to introduce a culture of personal privacy.

62 Consent is concerned with ensuring individuals are fully informed of the possible uses and sharing of their information and specimens, and have the opportunity to give or withhold consent for any of the uses.

63 Genetics has the added complexity that information gathered in one investigation may affect other members of the family, it may also have side impacts, for example unexpected issues of paternity may arise.

64 Genetics must ensure individual consent is registered for example:

3 Previously Known as the London Dysmorphology Database.



Consent to treat, examine or care.

Consent for a test to be performed.

Consent for information to be held at the genetics centre.

Consent for information to be shared with parties outside the genetics centre, e.g. for research.

Consent for the storing and re-testing of specimens.

Consent for sharing specimens with other centres.

65 In addition genetics makes additional demands including:

Consent to share information across family groups e.g. to aid diagnoses in other family members (this may involve information exchange between regional genetic centres).

Access to medical records of deceased patients.

66 The Human Genetics Commission published a report concerning the use of personal genetic data in 2002 (Inside Information, The Human Genetics Commission, May 2002). The Joint Committee on Medical Genetics will publish a report on confidentiality and consent in late 2005.

1.3.5 Long Term Relationships with Patients

67 Genetic conditions affect whole families across generations including ancestors and those yet to be conceived and born. Often genetic clinicians must set reminders for many years in the future (for example when a child comes of age); also knowledge and techniques may change prompting review and treatment of existing patients.

68 Systems must support these long term relationships through: long term information retention; flexible and time unrestricted alerting; and the ability to easily and quickly identify patients who may benefit from new investigation and healthcare techniques.

69 Genetic investigations may benefit from very long term retention of summary medical information outside the service (e.g. in the English CRS), for example cause of death and comprehensive disease registrations.

1.3.6 National Care Records

70 The English NHS is implementing an ambitious and comprehensive program of improvements to the IT infrastructure and applications, from a national high speed network (N3) to a nationally available care records service (NCRS). The other Home countries (Wales, Scotland and Northern Ireland) have plans for similar systems although with different scale, timescale and priorities. This provides the genetics community with opportunities and obligations.

71 The advanced plans in England make practical demands on systems immediately; in other countries the plans are more abstract. The English experience is very likely to affect the roll out in other countries so developments for the English NHS Connecting for Health programme are likely to provide benefit across the whole UK as plans become reality.

72 The opportunities include:



Improvement in information sharing within the genetics community and across disciplinary boundaries. The ability to communicate on a national scale.

Use of resources such as the Personal Demographics Service (PDS) as a definitive patient index.

Support multidisciplinary care through shared clinical records and communications.

73 In order to exploit the resources genetic systems must be ‘compliant’ for example use national code sets, standard communication methods and security mechanisms. Compliance puts a heavy burden on the functionality and quality of systems, genetic systems may require some major re-engineering to accommodate the requirements.

74 Clinical genetics are already feeling the affect of changes driven by national IT programmes and operational targets. For example Choose & Book means having systems able to integrate into the national CAB application. On the horizon are Payments by Results and 18 week referral to treatment targets. Any new systems must accommodate these, and be able to adapt to new national initiatives.

1.3.7 Laboratory Network Management

75 The demand for faster test turnaround times from service users and the genetics White Paper has led the regional genetic centres to explore ways to improve their use of laboratory resources. In practice this has led to laboratories forming networks, where laboratories specialise in particular tests enabling them to offer a fast efficient service to the whole network.

76 The genetics community works as a network at two levels: regional and national.

77 Regional networks have been created to share investigations due to:

Specialist nature of tests, low volume tests are often shared across groups of cooperating centres (supported through test export).

High throughput centres. High volume tests are concentrated in a specialist highly automated ‘test pipeline’ facility shared between cooperating centres.

78 Two examples of regional networks are described below, they are SCOBEC and London. SCOBEC is using the paper based requests to share tests across the network; London has implemented electronic requests between consortium members. The GenLYNC collaboration between the Leeds and Newcastle Molecular Genetics Laboratories is another example of a regional network using electronic communication.



1.3.7.2 SCOBEC

RGSOxford

RGSSalisbury

RGSCardiff

RGSExeter

RGSBristol

RGSCambridge

High ThroughputBRCA1/BRCA2

Service

Clinician

BRC

A1 Request

BRCA1 Request

Report/Results

Figure 1. SCOBEC Genetic Testing Network

Laboratories in Salisbury, Cambridge, Oxford, Bristol, Exeter and Cardiff have joined to become SCOBEC. The SCOBEC group are exploring ways of building high-throughput specialist test centres shared across the region. They are starting by concentrating on breast cancer testing (BRCA1/BRCA2) which combines high demand and long test times. Figure 1 illustrates the path of a BRCA1 test request from a clinician to their local regional centre, where it is passed to the high-throughput laboratory.

The high-throughput laboratory pseudonymise requests (e.g. the requesting laboratories’ ID number) therefore they get no details of the patients or referring clinicians identity.

SCOBEC have a flexible method of results reporting which may include:

Test results are analysed and interpreted in the high-throughput centre and an investigation report produced. The report is sent to the originating laboratory from where it is passed back to the requesting clinician. This method retains a clear audit trail in the originating laboratory and preserves the clinician’s relationship with their regional laboratory.

Test results and process information are sent in their raw form to the originating laboratory where analysis and interpretation takes place and an investigation report produced. Analysis and interpretation can be complex and time consuming, this model is very attractive because it distributes the reporting effort through the network and retains control, audit and information in the originating regional centre.

79 SCOBEC have analysed the laboratory workflow and built tools to help manage the process and the integration of high-throughput instruments. They report that the models of testing could be used to manage many of the molecular investigation types. For efficient test paths across genetic networks it is vital that laboratories are able to electronically exchange detailed information sets.

80 In some export models, test results are analysed and interpreted in the receiving laboratory and an investigation report produced. The report is sent directly to the requesting clinician



and a copy is sent to the originating laboratory. This model minimises transportation delays but carries the risk that clinicians will begin to bypass their regional genetics laboratories, and make management and audit more difficult.

81 At the national level the laboratories must report activity and quality measures in nationally agreed formats.

82 Network operation demands fast, reliable information transfer and could benefit from the ability to share information (through nationally agreed data standards) and resources (for example NHS staff and patient demographics systems).

1.3.7.3 London Genetics Consortium 83 The four Thames Regional Genetics Services (North West, North East, South West and South

East Thames) are part of a joint Genetics Consortium which is responsible for the commissioning of Genetics Services in London and the South East of England. The consortium is concerned with the overall management and financing of testing across the Regional Centres and they have identified integrated IT support as an integral part of this.

84 The consortium has commissioned the development of a common information system for the Regional Centres and is sharing the costs of development and support. As a result of this joint procurement, three of the four Regional Genetics Services in London are implementing the same information system. The consortium has invested in a team of developers to design, implement and support the system (known as Geneworks) which supports clinical, molecular, biochemical and cytogenetics.

ThamesGenetic Portal

Provider Genew orks Lab(e.g. Guy's)

Requester Genew orks Lab(e.g. St George's)

Test Request

Trackin

g Mes

sage

Authori

sed R

eport

Provider/Requester3rd Party System

Figure 2. The London Consortium

85 In addition to the Geneworks development, an initiative to enable the exchange of information between the Regional Centres in London is underway. The principal aim of this initiative (known as the Thames Genetics Portal) is to enable seamless exchange of patient information between the information systems of consortium members where appropriate to any particular task. Support for the Thames Genetics Portal is built into the Geneworks



Genetics Information System but Geneworks is not an absolute requirement to use the Portal. An Application Programming Interface (API) supporting the Portal for 3rd party suppliers is available. The API allows any system to communicate via the Portal. The architecture is illustrated in Figure 2.

86 A pilot service to be run through the Portal has been developed which enables the electronic requesting of Molecular Laboratory tests between Regional Centres.

87 The London service features the following:

Directory of tests supplied by each provider which can be managed by the provider.

Patient demographic and sample information exchange triggered by the sender's request

Tracking messages which are triggered by events defined by the provider in their system to provide alerts and information to the requester on the progress of work.

Sending of reports to the requester triggered by the provider authorizing the report.

Provision of consortium management information such as auditing of activity.

88 Once proven to be effective in London, this type of service could be scaled up to support the wider Genetic testing community.

1.3.8 Sample and Request Tracking and Tracing

89 The White Paper proposed improvements to sample tracking and tracing through the genetic community and a separate report set out the options for achieving this (NHS Genetic Laboratory Services - Scope and functionality of a tracking and tracing service, Genetics Reference Laboratory (Manchester), November 2004).

90 A comprehensive sample tracking and tracing service follows the sample through its complete lifecycle, ensuring information is passed reliably and accurately between all the testing stakeholders. Thus within the scope of a full tracking and tracing service is:

Reliable communication between all stakeholders (e.g. the test requester, laboratories and the genetic testing networks)

Reliable matching of sample to request and testing information through the lifecycle (e.g. unique identifier allocation, bar coding and RFID tagging).

Methods of tracking the progress of the sample through the test, plus flexible and comprehensive reporting of progress at local and network level (e.g. test checkpoints or reports against test tariff).

91 A tracking and tracing service compiles information about the progress of a sample through the test episode. The compiled information can be queried to provide:

Answers to tracing queries, for example a clinician wishing to get an estimate of time to test completion and reporting.

Management information, for example reports on the activity of a laboratory or a laboratory network. These reports could be used to audit activity and to provide information to better manage operation.

92 A tracking and tracing service may help solve a number of problems in the genetics service, for example:



Incomplete or illegible test request forms.

Reliable and safe transport of samples between test requester and laboratory.

Reliable matching between sample and test request information.

Inappropriate use of scientist’s time spent answering queries from requesting clinicians.

The problems of managing the import/export process.

The difficulty of analysing workflows within the laboratory, and streamlining the testing process.

Auditing the laboratories activity.

Difficulty in reliably and accurately matching samples and test information.

1.3.9 High Throughput Testing

93 At present information systems within genetic laboratories are used to store and manage information, they are rarely used to manage test workflow. This contrasts with traditional LIMS systems that are focussed on sample tracking, test process workflow management, instrument integration and report production, these LIMS focus on the sample and often have no patient indexes.

94 In general, current genetic laboratory systems:

Manage patient and family demographic information.

Manage relationships between clinicians, patients, test requests, samples, and reports.

Print worksheets for manual management of the test processes.

Capture summary test results.

Aid production of reports (e.g. report templates and text fragment assembly).

Help manage activity reporting.

95 The increased use of high throughput techniques and instruments (e.g. Pre/Post PCR, liquid handling robots and sequence analysers) means that traditional LIMS functionality may soon find a place in genetic laboratories. However this must be combined with the more information-focussed existing functions. Architectural models emerging from the genetic community are shown in Figure 3. The figure shows direct integration where the high throughput instruments are directly integrated into the genetic information system (e.g. passing information in and out through worksheets and using the software supplied by the instrument to control machine workflow); and indirect integration where a traditional LIMS is used to allow workflow management across a number of instruments. Indirect integration may be essential where a multi process procedure is to be automated, for example a BRCA pipeline.



GeneticInformation

ManagementSystem

LIMS

Instrument

Instrument

Instrument

Request/Sample

Report

GeneticInformation

ManagementSystem

Instrument

Instrument

Instrument

Request/Sample

Report

A: Direct integration B: Indirect integration

Figure 3. High Throughput Architectural Models

96 The Genetic Information Management System4 (GIMS) provides the core information store for the laboratory with overall management of clinician, patient, family, sample, request and test information, it must also provide overall test status information for tracking the progress of samples through the laboratory processes.

97 High throughput elements of the work may be managed by a LIMS, it accepts a dataset describing the procedure (e.g. procedure id and a plate layout) it manages the procedure (e.g. workflow support) and transfer of information between instruments appropriate to the procedure. Once the procedure is complete it hands back results to the GIMS where they can be collated with other results contributing to the overall test and allow the investigation report to be prepared and issued.

98 The desired partition of function between the systems must be defined locally, for example, where detailed workflow control is not required; the instruments may be integrated directly into the GIMS.

1.3.10 Cross-Disciplinary Working

99 Genetic services are involved in the diagnosis and treatment of many conditions and genetic laboratory results must often be collated with other results for interpretation. For example many laboratories have very close relationships with pathology departments and share information (in a controlled way) through shared information systems. In the North Thames Regional Genetics centre (Great Ormond Street) the scientists have access to the reports of other specialisms including:

4 Often referred to as the ‘demographic database’.



Haematology.

Virology.

Immunology.

Biochemistry.

Enzymeology.

100 The scientists consider this cross-disciplinary approach to testing a vital part of their service.

101 Some cytogenetic departments have been asked to consider integrated reporting with haematology and this type of integration is a stated aim of the cancer networks.

102 At present integrated working is supported by departments sharing information systems or carrying out bespoke integration projects. This OBS suggests that all systems provide standard integration support (e.g. HL7 v3 messaging) but this in turn demands that the genetics community adopt standards for exchanging information.

103 The national programmes for information systems are focussed on universal access to records and are providing infrastructure and standards to support this. Participation in the programmes will support better integration of genetic services and closely related disciplines, and allow better communication with the wider NHS.



The National Context



Section 1-4 The Genetics White Paper

1.4.1 Introduction

104 The full Genetics White Paper ("Our inheritance, our future - realising the potential of genetics in the NHS", DH, 24th June 2003) is available from the DH website. It sets out a comprehensive plan for preparing the NHS, including the investment of £50 million of new money over three years to help realise the benefits of genetics in healthcare. The White Paper promises:

A substantial investment in upgrading genetics laboratories, and a boost to the genetics workforce: more genetics counsellors, consultants and laboratory scientists.

More than £7 million on new initiatives to introduce genetics-based healthcare into mainstream NHS services.

A new Genetics Education and Development Centre to spearhead education and training in genetics for all healthcare staff.

New research programmes in pharmacogenetics, gene therapy and health services research to help turn the science into real patient benefit.

The OBS is concerned with the White Paper’s references to information systems, this section presents the requirements and their implications.

1.4.2 General Requirements from the White Paper

All participating laboratories will need to work with compatible systems.

New systems will be compatible with the Government's wider investment programme to modernise NHS IT systems and introduce electronic patient records

Systems must ensure confidentiality of patient information and consent to the use of information.

… genetic testing times will be cut and the results should be available to the following standards:

within three days where the result is needed urgently (e.g. for prenatal diagnosis),

within two weeks where the potential mutation is already known (e.g. because another family member has already been tested),

within eight weeks for unknown mutations in a large gene.

… enable better handling of work and communications within and between participating laboratories.



1.4.3 Laboratory System Requirements

105 New genetic Laboratory Information Systems will:

Allow samples to be tracked throughout the Network.

Facilitate communication and linkage between laboratories.

Provide better information for workload and quality management, including support for audit and validation of laboratory data.

Improve the quality, efficiency and timeliness of reporting results for patients.

1.4.4 Decision Support

106 The DH will encourage the inclusion of genetic knowledge in decision support systems as they are specified and developed in the future. Decision support systems may:

Look for genetic features in disease.

Prompt for screening or other preventive opportunities.

Take pharmacogenetic factors into account in prescribing.

Recall patients, sometimes after a period of many years, for whom earlier testing has identified an increased risk of chronic disease.

1.4.5 Practical Implications of the White Paper

107 At present the genetic services are most concerned with improving the throughput of laboratories. Reduction in genetic investigation reporting times means more automation of genetic testing services. The laboratories are currently investigating options able to help achieve automation.

108 The current generation of genetic laboratory systems are different from those employed in more traditional NHS testing services (e.g. Pathology). Due to the unique features of genetic services outlined in section 1.2.6, genetic laboratory systems focus on the management of patient and family information and less on the control of the sample through the test process. Traditional LIMS focus on the specimen or sample, they are designed to efficiently receive a sample, process it, and deliver a result. Achieving automation in genetic laboratory systems means integrating these two approaches. Section 1.3.9 describes these issues.

109 This OBS includes requirements intended to support all areas highlighted by the White Paper, the White Paper requirements directly supported by the OBS include:

Allow samples to be tracked throughout the Network.

Facilitate communication and linkage between laboratories.

Provide better information for workload and quality management, including support for audit and validation of laboratory data.




Recall patients, perhaps years later, for whom earlier testing has identified an increased risk of chronic disease.

110 The OBS includes requirements intended to provide the users of genetic services with better visibility of genetic services and help in selecting appropriate services (e.g. service directories, service guidance and decision support). However ensuring the wider NHS considers genetic disease in other care pathways means better education of clinicians and inclusion of genetic factors in other decision support systems and care pathways. The national programmes for improved IT support are intended to improve access to information and provide decision support. It is vital that the genetic community contributes to these in order to ensure the wider aspirations of the White Paper (‘mainstreaming’ genetics) are achieved, for example:

Take pharmacogenetic factors into account in prescribing.

Look for genetic features in disease.




Section 1-5 International Programmes

1.5.1 Introduction

111 Each of the countries in the UK has plans for improving computer support across health services and all intend to set up a nationally available care record. The English programme has progressed furthest and the practical implications for specialist healthcare systems such as those employed in genetics are emerging. The English Choose and Book (CAB) programme will affect clinical genetics immediately; CAB demands that referral processes and systems are made compliant to national standards supporting patient choice and electronic appointment booking.

112 Although the plans in different countries are distinct, there are likely to be common approaches and the lessons learned in England are likely to inform developments elsewhere. Cross border communications are common in the NHS and the national programmes are recognising the need to support these and beginning to explore methods for practical solutions, for example through common patient indexes and compatible coding and messaging systems.

113 This section outlines the ICT strategies in the UK NHS services. The English programme is in advance of the others, thus the section provides more detail of the English plans and the OBS uses the English plans as a model for national system integration.

114 The section ends with a summary of the implications for genetic systems and outlines some tasks necessary for national integration. However even in England the exact details of national system compliance are still emerging and may be subject to change.

1.5.2 The English NHS Connecting For Health (NCfH)

115 Historically, IT systems in the NHS have been procured on an ad-hoc basis to meet local requirements. There have been no national standards for organising or coding data in information systems, or exchanging information between them. This has led to a situation where IT implementation is patchy, and where systems do exist, the information stored within them cannot easily be shared with other systems.

116 NHS Connecting for Health, through the NPfIT, intends to overcome these incompatibilities by ensuring a consistent approach to IT procurement and development within NHS systems. The NPfIT is an ambitious wide ranging programme that will:

Provide basic IT infrastructure including reliable secure networks, security services and computers on desks.

Develop national resources including:

A life long care record available from any location within the NHS (the Care Records Service - CRS).

An e-booking infrastructure allowing patients to choose a convenient time, date and location for their appointments (Choose and Book).



An electronic prescribing system linking the NHS with pharmacies.

Messaging services and data sets allowing local systems to communicate effectively.

117 “National Service Providers” (NASP) will develop the national services. Regional IT procurement and development will be coordinated through “Local Service Providers” (LSPs) who have been engaged by five Strategic Health Authority Clusters.

118 Genetic Information systems must conform to NCfH standards. The NCfH defines specialist systems as ‘Departmental Systems’, which, where necessary, will be integrated at a local level, for example with hospital systems managed by the LSP.

Regional Cluster Services

National Spine Services

Care RecordsService (CRS)

PersonalDemographicsService (PDS)

Transaction and Messaging Service (TMS)

Secondary UsesService (SUS)

ElectronicTransfer of

Prescriptions(ETP)

Choose andBook Service

(C&B)

Clinical SpineApplication

(CSA)

Access Control Framew ork

Local Service Provider X5...Primary Care

TrustsHospitalTrusts

Mental HealthTrusts

AmbulanceTrusts

CRS CompliantDepartmental

Systems

Figure 4. NCfH System Architecture

119 An overview of the NCfH architecture is shown in Figure 4. Provision is split into two main areas:

The ‘Regional Cluster Services’ are provided by the Local Service Providers5 (LSP). The LSPs are responsible for providing and integrating core services throughout the

5 LSPs are Accenture (North East and East), CSC (North West/West Midlands), Fujitsu (South) and BT (London).



regions NHS trusts. There are five regional clusters which are North East, East, North West/West Midlands, South and London.

The ‘National Spine Services’ integrate together the LSP services and provide national resources including the communications infrastructure and the national care record6. Table 2 describes the national services.

Table 2. NCfH National Services

Service Description Choose and Book (C&B). C&B links primary care with secondary care services. It

provides electronic support for the referral and appointment booking process. In addition the directory of available services allows patients to exercise choice in the selection of service provider. PCTs will be expected to offer up to five providers including independent suppliers. The service will begin with first outpatient appointments (GP to hospital trust) but it is intended to extend this to tertiary appointments and ultimately scheduling across the complete care pathway.

Electronic Transfer of Prescriptions (ETP).

ETP is intended to replace the current paper based communications between clinicians and pharmacy with direct electronic data exchange.

Care Records Service (CRS). The CRS provides the central health record, it will combine a central data store summarising important clinical information and care episodes (e.g. allergies, adverse reactions to drugs and details of any visits to A&E) and provide links to detailed information held on local systems.

Personal Demographics Service (PDS).

The PDS will provide the definitive record of patient demographics information across the whole NHS. It will replace the NHS Central Index and the National Strategic Tracing Service (NSTS). At its core will be the unique identifier provided by the NHS Number.

Secondary Uses Service (SUS).

The SUS will provide information for purposes other than direct clinical care. The service will protect the confidentiality of patients and will provide timely, pseudoymised patient-based data. It is intended to support:

planning

commissioning

public health

clinical audit

benchmarking

performance improvement

research

clinical governance

Initially SUS will take on the data flowing through the current

6 BT have been contracted to develop national services, they are known as the National Application Service Provider (NASP).



NHS-Wide Clearing Service (NWCS) and support the implementation of Payment by Results. Over time SUS will be enriched by other data sources, including cancer waiting times, disease registries and clinical audit information. The service will also generate some central returns. On-line access to analytical tools and services will be available for research

Transaction and Messaging Service (TMS).

The TMS provides the communications infrastructure linking all the local, regional and national applications. It combines the physical network (NHSNet, N3) and messaging based on the HL7 standards.

Access Control Framework (ACF).

It is vital that NHS systems protect patient confidentiality and respect information sharing consent. The ACF contributes to the security infrastructure by providing a robust role based authentication and access mechanism.

Clinical Spine Application (CSA).

The Clinical Spine Application (CSA) provides a stand alone interface to national services allowing access to NHS staff whose local applications are not fully integrated.

120 The NCfH plans do not include all NHS services, they are split into three service bundles which are:

Core Service Bundles which will be provided through LSPs and financed through the national programme. These include patient registration, recording assessments, scheduling appointments, electronic booking, order communications and results reporting, emergency care support and clinical support systems.

Additional Service Bundles which may be purchased through LSPs (but the LSPs do not have exclusive rights) and are not funded through the national programme. These include radiology systems, laboratory systems, helpdesk support, financial payments, training, document management and pharmacy stock control.

Future Service Bundles NHS trusts are free to purchase any system of choice.

121 In practice the core service bundles will be based on three applications (ISoft Lorenzo, Cerner Millennium and IDX Carecast) these will be hosted by the LSPs and will provide trusts with the basic patient administration similar to existing PAS/HISS systems and will include enhanced clinical support. Additional service bundles will be integrated by the LSP to the core applications and offered as independently commissioned items to trusts.

1.5.3 The Welsh NHS – Informing Healthcare

122 The strategy for IM&T in Wales is set out in the document “Informing Healthcare” available from the website at www.wales.nhs.uk/ihc.

123 Informing Healthcare is based on a vision of patients, carers and professionals working together, supported by the latest evidence, to reach agreement on appropriate and cost effective healthcare for the patient. It states that the resulting decisions and actions – referrals, tests, treatments, discharge – should be transparent and open to evaluation, that outcomes should be recorded and used to improve services and that the whole health transaction should be carried out in a secure and confidential way.

The strategy focuses on five key benefit areas.



A Single Record that is accessible to those who require the information, including patients and carers. The record will not hold all information in one place, but it will allow health professionals to access all the information they need, and only the information they need, about a patient whenever and wherever they need it. This access will take place in a secure environment, and profiling of users will ensure that it is limited to what any given professional needs to know.

The long term goal is the development of a fully integrated approach to health and social care records, although total integration of these records is currently beyond the scope of this strategy. Meanwhile, all steps will be taken to ensure that developments in healthcare records and social care records are strategically convergent.

Workforce Empowerment. The implementation of Informing Healthcare will involve significant changes for the workforce, both in developing new skills and finding new ways of working. The exploitation of high quality information is likely to become more central to clinical culture and to consultations with patients.

The new skills required will range from basic IT and information management skills through to sophisticated critical appraisal techniques and statistical analysis, depending on the requirements of the individual. Informing Healthcare will ensure that the right balance exists between the core skills that all health professionals should have and the availability of specialist health informaticians to undertake more complex tasks.

Patient and Carer Empowerment. The change of culture towards shared decision-making, with the patient and carer becoming part of the healthcare team.

Service Improvement. The introduction of technology without changed working practices will have little impact. Changed working practices without new technology will be harder to sustain in the long term, and may miss important effectiveness and efficiency gains. Most importantly, new technology makes possible new ways of working that could not otherwise succeed.

Knowledge and Information Management. A re-assessment of the measures needed to assess whether goals are being met is likely to lead to a combination of new measures being developed and some old measures and data collection processes being stopped. New measures will be supported by the introduction of the Single Record, as it will augment clinical data capture. Better use of the information collected will be supported by the education and training planned in the Workforce Empowerment stream of Informing Healthcare.

124 Informing Healthcare will be a project-based strategy. The Programme will identify individual projects and products and ensure that they are delivered in a coherent way in support of the overall change programme. The Programme will not undertake ongoing information or IT service provision. Such provision will be the domain of national and local health organisations in Wales and, where appropriate, private sector suppliers.

125 While the Programme will be responsible for delivering strategic products and overseeing health service-wide projects – enabling, supporting and monitoring progress on the strategy – it will not take responsibility for organisational and professional change. This responsibility will continue to rest with Chief Executives and Boards of health organisations.

126 A range of applications exist which have – properly implemented – been proven to bring benefit in healthcare and these should be early candidates for investment across Wales. They include:

Electronic communications.

Requesting and reporting of tests.



Picture Archiving and Communication Systems (PACS)

Electronic Prescribing.

Care Scheduling.

1.5.4 NHS Scotland - Ehealth/IM&T Strategy

127 The ICT strategy website is www.show.scot.nhs.uk/imt. It gives the overarching aim as:

“Our goal is to deliver an Integrated Care Record jointly managed by patients and professional NHS staff with in-built security of access governed by patient consent.”

128 The strategy states that information must flow as part of the many and various journeys through the Scottish NHS and the other caring agencies that patients can take. Shared Care Records are therefore about integration of information at four key levels:

Local GP/ specialty electronic patient records, such as GP system or A&E system or a diabetic or cancer record, linked if appropriate to the Local Integrated Care Record.

Local Integrated Care Record: NHS board-wide information system holding test results, clinical letters and summaries of care contributions. These may be assembled through speciality electronic records to give a clinician an up-to-date “view” of all information held about the patient in the SCI Store repository which the clinician is authorised to access.

National Integrated Care Record: NHS Scotland-wide based on the Scottish Care Information (SCI) Store and holding copies of information from other national systems such as immunisation as well as summaries of information from the Local Integrated Care Record.

The immediate objectives are to:

Progressively integrate, improve and deliver key information to the point of active care and self care.

Lead through the clinical and patient agendas.

Build commitment and collaboration between all stakeholders, and address all elements which make for success.

Build upon mandatory national components such as the Community Health Index (CHI) and SCI Store.

Address the legacy of inconsistent systems by not sanctioning alternatives acquired locally where a national system has been established.

Address the lack of equity and modern systems across NHS Scotland through collaborative and supported procurement and development.



1.5.5 NHS Northern Ireland – HPSS ICT Strategy

129 In March 2005 a ten year plan for health and social services information technology in Northern Ireland was announced, full details are available from http://www.dhsspsni.gov.uk/publications/2005/HPSS%20ICT%20Strategy.asp.

130 The Health and Personal Social Services (HPSS) strategy has two major themes for ICT development

Electronic Care Records

Electronic Care Communications.

131 The electronic care record will be created for every patient and be accessible wherever and whenever there is a legitimate need. The record will provide current and historic information on patients and contain structured data, text and images generated from a variety of sources.

132 Electronic Care Communications will include:

Appointments.

Referrals between care professionals.

Requests for services and communication of the outcome.

Discharge letters and other follow-up communications.

Prescribing.

133 There could also be added benefit from:

Providing care professionals with current information on waiting times for referrals and options on where to refer.

Automating data input wherever possible to simplify administrative tasks and improve data accuracy and completeness.

Providing intelligent support, for example to the prescribing process or the selection of investigations.

134 ICT support for care communications and transactions will help capture key data to contribute to electronic care records.

1.5.6 Implications for Genetic Systems

135 Each of the national programmes contains an intention to provide:

A national care record.

A national communications infrastructure.

136 For the genetics community to play a full role in the national plans they must ensure that:

1. Standards suitable for the genetics exist, for example message sets able to express the needs of genetic service.

2. Systems are able integrate into the national infrastructure, for example comply with common standards and implement standard mechanisms.



137 The first of these is the responsibility of the genetics community as a whole, to decide if they wish to join the national programme and if so, to understand the defined national standards and extend the standards to fully support genetic services.

138 The second is the responsibility of genetic system developers; they must build systems capable of integration. The English plans have begun to define a compliance mechanism so this is taken as a model.

1.5.6.2 Implications for the Genetics Community 139 The first decision for the genetic community is whether the national programme offers

benefits to their users (the patients) and/or the service itself, and whether the necessary resources in time and cost can be found. In England the national programme states that

“It is not required to make ALL systems of a certain type “compliant” – the costs must be offset against the likely benefits.” [National Programme for IT, Initial Guidance for existing system suppliers, version 2.1, 4 October 2004].

140 The aspirations of the genetics White Paper and the genetics community include operating as a network and a focus on putting the patient at the centre of care. This fits exactly with the intentions of the national programmes, moving from an organisational focused service with ‘islands of information’ within specialist departments to a service that centres information (and care) on the patient and allows all care practitioners access to all relevant information (according to consent) regardless of location or specialism. Thus the resources offered by the national programmes are likely to help the genetics service achieve the aspirations of the White Paper and expressed in the community engagement for this project.

141 Central to achieving integration into the national programme is information standards, the ability to support electronic transactions (e.g. electronic booking, ordering and reporting) and exchange information (e.g. pedigrees). The information standards must be adopted across the whole community and supported by the information systems they employ.

142 The national programme has defined information and message sets for key services that include all common clinical communications for example:

Patient demographics.

NHS resource indexes (organisations, locations, and staff).

Referrals and appointments (necessary for electronic booking).

Discharge.

Test and investigation orders.

Results reporting.

143 The message sets are likely to form a framework for genetic communications, it is up to the community to:

Understand the available message set.

Identify gaps.

Identify areas where the standard is not adequate (for example genetic result reports are sometimes very complex, does the standard report message satisfy genetics?).

Ensure alignment with associated services, for example investigation communications proposed by the pathology community.



144 Where the national standards do not satisfy genetics the community must define acceptable standards and steer them through national adoption schemes. These standards are intended for communication with service users, for example clinicians referring into genetic services. In addition, the genetics service must define standards for communications within the community for example information exchange between laboratories. These will include national performance reporting standards.

145 The first impact of NPfIT to be felt by Clinical Genetics is likely to be the Choose and Book programme. This intends to allow referring clinicians help their patient select a suitable and convenient care service (from a choice of up to five providers) and book an appointment immediately through an online application. This model of referral does not match the genetic process where the first contact is often not an appointment but the exchange of a family history form and where many referrals do not result in an appointment.

1.5.6.3 Implications for Genetic Systems 146 In England the departmental systems must interface to NPfIT applications at the local level,

for example genetic systems will need to integrate with the systems provided within their host NHS hospital trust. This will allow information exchange at the local level (e.g. trust based interdisciplinary care) and through the spine to regional and national resources and services (e.g. communication across all regional genetic services). Systems should be able to demonstrate that they:

Are of sufficient quality (e.g. show robust development procedures and provide acceptable support, maintenance and training services).

Comply with NCfH security mechanisms.

Comply with NCfH information and messaging mechanisms (e.g. use standard data sets and messages).

147 In practice this is likely to mean that ‘compliant’ genetic systems must demonstrate:

Support of standard messaging protocols and interfaces (in England this is based on HL7 v3).

An ability to securely integrate with programme wide authentication and single sign on mechanisms

Compatibility with programme wide role based access models.

Ability to integrate with national and regional resources such as patient demographic indexes, resource, organisation and staff indexes.

Compatibility with programme mandated coding schemes, for example in England SNOMED-CT.

Clinical genetic systems must integrate with the Choose and Book functionality.

148 In the English national programme this level of integration is likely to be best achieved through cooperative working with the Local Service Providers and the vendors providing their core applications.

149 Compliance places heavy demands on system developers and many of the current generation of genetic information applications would need significant enhancement in order to achieve compliance. The cost of compliant systems is likely to reflect the step change in development and maintenance standards. In addition, the commonly encountered in-house developments are unlikely to achieve compliance unless they are allowed the resources to develop appropriate development, maintenance and support services. The genetics community must



consider if the advantages of use of compliant systems is worth the increased costs and if so, where the funding for it can be found.



Clinical Genetics



Section 1-6 An Overview of Clinical Genetics

1.6.1 Introduction

150 Clinical Genetics provides a diagnostic and genetic counselling service for individuals and families with, or at risk of, conditions which may have a genetic basis. Genetics is a unique specialism due to its primary concern with families rather than individuals. The two most common referrals to clinical genetics services concern:

Children with developmental problems.

People with a family history of cancer.

151 People who may benefit from referral to a genetics centre include:

Couples with a history of difficulty becoming pregnant, repeated pregnancy losses, stillbirths, birth defects or early infant deaths.

Individuals with a family history of genetic disease.

Couples who are close blood relatives (consanguinity).

Pregnant woman or infants who have been exposed to a medication, drug, radiation, or other environmental agent.

152 The centres accept referrals from all parts of the health services including GPs, secondary care specialists and sometimes self referrals from members of the public (for example the centres receive calls from individuals concerned about their family history of disease). Referrals are classified as, for example, urgent, soon and routine.

153 Activities in the centres include:

Diagnosis.

Co-ordination of investigations (including pre-natal diagnosis).

Risk assessment and co-ordination of testing for those at risk.

Genetic counselling for individuals and as family groups.

Contacting and testing relatives.

Continuing contact and support.

Reviewing at-risk groups when knowledge or techniques change.

154 Figure 5 provides a very high level view of clinical genetics activities.



Referral Review byConsultant

PedigreeAnalysis

Reject Discharge

Care EpisodeManagement

Ongoing CareManagement

Discharge

Figure 5. Clinical Genetics Overview

155 Each referral is reviewed by a consultant to ensure it is appropriate. Inappropriate referrals are often received, for example, sometimes simple analysis of the referral can indicate low risk of inherited disease and patients showing symptoms of serious disease should be referred directly for treatment before considering genetic investigation. If the referral is appropriate the consultant will decide the next action.

156 The first patient contact is almost always to collect information for building comprehensive pedigree information. First contact is rarely a clinic appointment, it may be a phone call or a letter accompanied by a detailed family history form (sometimes this accompanies the referral). Genetic counsellors use the collected information to build the pedigree including medical history, for example with reference to cancer registries and death certificates. Pedigree drawing programs such as Progeny and Cyrillic are used extensively in this work.

157 Once the pedigree has been developed, it may be analysed by genetic counsellors and consultants (sometimes helped by computer applications, for example to draw and analyse the pedigree data). The analysis informs the next action. If there is little or no risk to the patient, they may be discharged with a letter describing the findings. If there is risk the next actions may include an appointment to discuss the findings and take samples for confirmation of the findings through genetic testing. The findings may have implications for other family members so they may be included at this point.

158 In some circumstances genetic counsellors will provide counselling at the hospital or in the home. The role of genetic counsellors may also be extended to provide a link with primary care for clinical and education purposes.

159 Once the genetic condition is established the immediate actions are planned, these may include examination, investigation, test, diagnosis and counselling). Many conditions require a multi disciplinary approach to care, for example Marfan Syndrome combines care from genetic ophthalmology and cardiology specialists. The overall care package is often managed by the genetic specialists, for example a specialist nurse providing the link between diagnosis, counselling and the care services.

160 Many genetic conditions require long term care or observation, the genetic specialists take responsibility for planning long term surveillance (e.g. for late-onset disorders, provision may be made for follow up of children when they reach the age of consent). In addition they will monitor new techniques and tests for applicability to existing patients.



1.6.2 Clinical Genetics Workflow

161 Figure 6 provides an overview of the clinical genetic workflow and the tables following describe each stage in more detail.

Care EpisodeManagement

Appointment(s)

Referral Receipt andRegistration

ReferralReview

Return toReferrer

Reject

Information Collection

Clinic Management

Patient Liaison

Test Request/Receipt

Referral/WaitingList Policy

Discharge

Clinical Liaison

Ongoing Care Management

Case Review

Patient Liaison

Family Liaison

Decision to Refer

Referral (urgent, soon, routine)

InformationAnalysis

Further Action

Patient Liaison

Registries

LaboratoryServices

Clinical Meetings

Patient Liaison

Figure 6. Overview of the clinical workflow



1. Decision to Refer

Description Entry point into clinical genetics. Referrals are often generated from enquiries from medical practitioners or members of the public (for example my family has a history of X, am I at risk? I am thinking of having children but my cousin has X). The clinical geneticists operate a type of ‘help line’ and a high level of dialog with patients is necessary.

Referrals are received on paper, fax and by telephone. They come from any part of the NHS and direct from the public, referrers include:

Hospital Specialists.

GPs.

Self referrals from potential patients.

Referral derived from existing patients, e.g. a relation found to be at risk.

Notes Referrals containing complete and accurate information should pass from the referral sender to the receiver.

NHS resource integration (NCRS)

Emerging infrastructure brings the potential to accept electronic referrals. For example through the English NHS’s Choose and Book programme. However as noted in section 1.5.6.2 the genetics referral model does not directly match the C&B workflow.

2. Referral Receipt and Registration

Description Initial entry of referrals into the administrative system (e.g. captured on the computer system).

Referrals are received on paper, fax and by telephone.

Referrals are registered by all members of the staff. Genetic Counsellors or Consultants may register a referral whilst a patient or clinician is on the telephone. Written referrals may be registered on the information system by administrative staff.

Notes This element deals with the administrative receipt of referral details. It must capture the information necessary to communicate effectively with the stakeholders of the referral (the patient, the referrer, the GP and the organisation or individual responsible for the cost of the episode of care).

The complete and accurate details of the referral must be captured in a consistent manner. Details must include:

Demographics (name, address, contact details, sex, date of birth, language).

Referring clinician details (name, organisation, contact details).

Primary Care (GP details - name, organisation, contact details).

Commissioning, contract and invoice details.

The reason for referral.

Referral tracking information, for example the date and time of the



referral receipt.

The referral tracking information allows the information system to generate management reports, for example waiting times.


Central indexes of patients and clinicians may be used to confirm patient and NHS demographic details (e.g. use of the PDS to get address, NHS Number and GP details7).

3. Referral Review

Description This task ensures referrals are appropriate and dealt with appropriately, for example that they have come to the right place and, if so, the correct initial actions are chosen.

It may occur anywhere in the genetics centre, at a workstation or in a meeting room. It is an information review task that could be carried out wherever the information is available. This is a clinical review; it may be carried out by a single clinician or at a referral review meeting.

Notes The referral may be rejected (referred back) if it is considered inappropriate (for example obviously low cancer risk may be rejected with an explanatory letter). If it is accepted it is allocated to a clinician/counsellor.

Decisions in this task include:

Accept or reject the referral (rejections are accompanied by an explanation and recommendations).

Allocate the referral to an appropriate specialist consultant, counsellor or sub-specialist team.

Allocate the priority of the referral.

Select the most appropriate initial actions for the referral for example send a family history questionnaire and/or book a clinic appointment at an appropriate central or peripheral clinic.


Clear, complete and accurate communication of the referral review results to the referring clinician could benefit from a better connected health service.

4. Information Collection

Description Collecting the pre-clinic information in order to build the pedigree diagram and collate any relevant clinical information.

Many genetic investigations are concerned with the likelihood of an individual inheriting a condition from family members. Thus building a comprehensive pedigree diagram is the first task. An example pedigree diagram is shown in Figure 7.The patients are sent a detailed questionnaire asking questions about family members and disease history.

Telephone contact between counsellor and patient may occur.

7 This functionality is currently provided by the National Strategic Tracing Service.



Notes In some centres the referral is not considered active until the family history form has been returned. Once it has been received some preliminary consideration of the information may result in a discharge, for example where little risk is evident. One centre estimated the 40% of cancer referrals are rejected/discharged without a clinic appointment (non return of form or little risk).


There is some potential for direct patient input via a website (e.g. myhealthspace) however this is skilled task and mediation by a health professional is usually needed to elicit comprehensive information.

Figure 7. Example Pedigree Diagram8

5. Information Analysis

Description On receipt of the information from the patient, the genetic counsellor or consultant will build a pedigree diagram and complete with details, including previous disease (phenotype), cause of death and completed genetic tests. This may be restricted to the information given by the patient or may involve detailed research, for example contacting cancer registries, public bodies for death certificates and investigating records of the provider service and other genetic centres.

The counsellor/consultant analyses the pedigree information in order to assess the probability that the patient may be at risk from inherited disease, they may employ computer applications able to automatically analyse the data, for example BRCAPRO for assessing the probability that an individual carries a mutation of the BRCA1 and BRCA2 genes, based on family history

8 The pedigree diagram shown is part of an example presented by Progeny Software. LLC.



of breast and ovarian cancer.

The analysis of the pedigree information may identify other members of the family that may benefit from genetic investigation.

Notes The task builds as complete a picture as possible in order to decide upon next actions, for example complete an initial risk of an inherited disease. The outcomes of the analysis include:

Discharge, for example there is no likelihood of inherited disease.

Appointment, for example the patient needs counselling or testing.

Further family investigations, for example, other members of the family are shown to be at risk and/or further analysis requires other family members to be investigated/tested (sometimes the original patient has no risk but other family members must be investigated).


Analysis often depends upon the availability of comprehensive information regarding individual and family history. Centrally managed resources of family relationships, disease history and test outcomes could be very useful. Consent for sharing information across family investigations must be gained.

6. Care Episode Management

Description The day to day management of care.

Building on the initial information collection and analysis the genetic counsellors and clinicians consult with the patient to diagnose conditions, calculate risk of inherited conditions and counsel on the affect of conditions and the choices facing patients (for example whether to have children or consider preventative surgery).

The tasks may occur anywhere patients and genetic professionals meet including:

Clinics and treatment rooms in the specialist genetic centres.

Outreach Clinics, for example local hospitals or primary care surgeries.

Ward or hospital department consultations.

Visits to the families’ homes.

Consultations and analysis may be carried out away from the patient, for example by the clinician alone and during telephone consultations, these may occur:

In the clinical setting (offices, meeting rooms, nursing stations).

Outside the clinical setting (home, car, hotel).

The tasks are carried out by Genetic Consultants, Genetic Counsellors and Genetic Centre Administrative Staff.

Notes There are many elements to care management including:

Patient and family liaison, records of spoken and written correspondence.

Clinic administration including appointments, clinic management,



staffing (e.g. including a translator), scheduling, family appointments and open access clinics.

Case reviews organisation and clinical summaries.

Test request, test track and trace, result reports.

Details of correspondence with referring clinicians.

Clinical Information Management, collection, organisation, access and distribution (sharing) of clinical information, including:

Coded information (for example OMIM and LDDB).

Text - free text areas, attached documents, scanned documents (for example test reports).

Images – for example photographs, x-rays and ECGs.

Information is filed at the family level as well as patient.


In England NCfH intends to create a universally available patient record and is rolling out Picture Archive and Communication Systems (PACS), these will provide valuable tools for sharing patient records, reports and diagnostic images.

7. Ongoing Care Management

Description Genetic conditions often require ongoing care and surveillance throughout a patient’s life and may continue through future generations. For example a child diagnosed with a genetic condition, or at risk of passing on a genetic condition at birth may require counselling at age 16, or when a pregnancy is considered.

It often falls to a genetic counsellor to coordinate the ongoing care of individuals and families with genetic conditions, for example Huntington Disease benefits from a symptom-specific, interdisciplinary approach to care.

New techniques (for example a new test) may have implications for patients of the genetics centre long after their initial referral. Existing patients should be recalled if they may benefit from new tests or understanding.

Tasks are carried out by Genetic Clinicians, Genetic Counsellors, and Genetic Centre Administrative Staff.

It should be noted that genetic clinicians indicated that few accepted ‘care plans’ for genetic conditions exist due to the large number of rare diseases and a lack of agreed evidence of benefit. Where plans do exist, they are developed locally.

Notes Long term surveillance and care management of individuals and families, includes:

Recall for investigation, e.g. when symptoms may occur.

Ensuring treatments and investigations are carried out.

Scheduling internal case reviews.

Recalling patients that may benefit from the new techniques or new tests.

There should be no time limit on alert setting.




Many genetic conditions benefit from cross-disciplinary surveillance and preventative care. Good communications between genetic centres and other NHS services could help organise the care effectively.



Genetic Laboratory Services



Section 1-7 An Overview of Laboratory Services

1.7.1 Introduction

162 Genetic testing falls into two categories, the mature cytogenetics services and the more recently established molecular services. The two specialties are distinct, however the distinctions are blurring (cytogenetics are increasingly employing molecular techniques such as FISH and CGH). Genetics centres often manage cytogenetic and molecular genetic services as a single unit (e.g. sharing a single information system). This document deals with laboratory service as one and highlights the areas where differences lie.

1.7.2 Cytogenetic Testing

163 Cytogenetics9 includes the laboratory services for diagnosis of chromosomal abnormalities, both congenital and acquired, that can be detected using high-resolution microscopy, molecular cytogenetics (e.g. FISH) or other specialised techniques (e.g. CGH). Activities include the diagnosis of:

Pre and post-natal chromosome abnormalities

Chromosomal abnormalities in foetal material

Cancer (haematological and solid tumours)

Molecular cytogenetics

164 Cytogenetic laboratories are staffed by clinical scientists and technicians who are using an increasing range of techniques to undertake a wide range of investigations on blood, tissue, tumour and haematological malignancy samples, and on amniotic fluid and chorionic villus sampling (CVS). The main patient groups that benefit from these services are: pregnant women previously known to be at increased risk or those identified through screening programmes, babies and children with birth defects or developmental delay and patients with leukaemia. Other user groups include males and females with reproductive problems. The clinical scientists interpret complex results for clinicians and play a vital role in the development of new technologies and services.

165 Samples are typically grown in culture media for a number of days or weeks. When a cell culture is ready to be harvested its growth is arrested. The arrest halts the cell cycle at metaphase where the nuclear DNA is organised into discrete chromosomes. Metaphase chromosomes are fixed onto microscope slides and are analysed by cytogenetic scientists. Analysis types include:

Chromosome Analysis, the traditional visual examination of the chromosome by optical microscopy.

FISH (fluorescent in situ hybridization). Probes that bind to specific chromosome structures.

9 Cytogenetic and Molecular service descriptions are adapted from Specialist Services Definition no. 20.



CGH (Comparative Genomic Hybridization) a ‘molecular-cytogenetic’ method for the analysis of regional changes in the DNA content of cells. For example, using epiflourescence microscopy and quantitative image analysis, regional differences in the fluorescence ratio of tumour vs. control DNA can be detected and used for identifying abnormal regions in the tumour cell genome.

QFPCR (Quantitative Fluorescent Polymerase Chain Reaction) is a rapid method for the detection of common numerical chromosome disorders.

MLPA (Multiplex Ligation-dependent Probe Amplification) a PCR-based commercially available assay. This methodology allows relatively large sample volumes to be run simultaneously, significantly reducing laboratory turnaround times.

Micro-Array, at present a research technique. An array of DNA or protein samples that can be hybridized with probes to study patterns of gene expression.

1.7.3 Molecular Genetic Testing

166 Molecular genetics techniques may be used for pre and post symptomatic diagnosis and for determination of asymptomatic carrier status for inherited disorders, or post symptomatic diagnosis of genetic conditions due to new mutations. Testing usually involves extraction of DNA (or sometimes RNA) from lymphocytes and other tissues and analysis of causative mutations or tracking a disease gene through families.

167 Molecular techniques may also be used to aid diagnosis or aid in management of acquired disease, such as malignancies. Testing involves extraction of RNA or DNA from tumour cells and analysis for the presence of disease associated mutations or clone-specific gene rearrangements. These markers can be used to track the malignant cells throughout the disease/treatment course and for relapse prediction.

168 These laboratories undertake DNA analysis using a wide range of techniques to identify disease-causing changes in specific genes. The range of genetic disorders amenable to such analysis increases year on year and there are continual changes in technology. Typically laboratories provide a service for a number of common disorders (e.g. cystic fibrosis, fragile X, mental retardation syndrome) plus a number of specialised services for “rare” disorders on a sub-national or national basis. These are staffed by clinical scientists and technicians who undertake this work. The clinical scientists provide interpretative reports and have a very important role in the development of new techniques and services.

1.7.4 Laboratory Integration

169 Many laboratories are integrating their laboratory services. In practice this means sharing staff (management and operational), procedures (e.g. booking in) and information systems. Integration has many advantages including:

Common approaches to testing and shared procedures, for example a common booking in procedure.

Shared resources, for example patient demographic indexes.

Ability to share information, for example common indexing and access to cytogenetic and molecular test results and reports.



Shared test and analysis procedures. Many tests are blurring the distinction between molecular and cytogenetics, for example cytogenetic laboratories are exploring the application of microarrays, which require DNA extraction.

Some conditions require both cytogenetic and molecular genetic tests, for example NICE recommends this approach for Prader Willi Syndrome.

Consistent approach to referrers, for example content and form of clinical communications including investigation reports.

170 In some centres integration extends to include clinical genetics. Genetic information systems must be able to support both autonomous and integrated genetic centres. This means the system must include robust role based access in order to allow controlled sharing of information.

171 In addition to integration within genetics some centres work closely with other laboratories, for example haematology, virology, immunology and biochemistry. This integration is especially important where there is cross-disciplinary working in the diagnosis and treatment of particular conditions.

1.7.5 Genetics Laboratory Workflow

Booking In Allocation Testing ReportingAnalysis

Export

Figure 8. High Level Laboratory Workflow

172 Figure 8 shows a high level view of the general testing workflow (omitting the service users). First, test requests and samples are booked in and demographic and clinical information is captured in the information system. The work is then allocated to a responsible person or team within the laboratory who makes decisions about the appropriate tests, sometimes the samples are exported to another laboratory. The tests identified at allocation are then performed. The analysis phase draws together the test results for interpretation. Finally the information from the analysis is presented to the test requester in the form of a report.

173 A more detailed laboratory workflow representing cytogenetics and molecular genetics is illustrated in Figure 9. Each element is described in tables following the diagram.



1. InvestigationRequest/Sample

Collection

2.Investigation

Request/SampleReceipt

Sample

Test Request

3. SampleDistribution

6. Analysisand

Verif ication

7. ResultsReporting

8. Lab Management

(e.g. work schedule, process management, audit)

5. Sample Management

(e.g. storage, disposal)

9. Network

Management

4. TestExport

Figure 9. Detailed Laboratory Workflow

1. Investigation Request/Sample Collection

Description Investigation requests may be made by any appropriate individual; these are mainly specialist clinicians in the NHS but may include GPs and private healthcare providers.

The requests come from outside the laboratory wherever investigations may be requested, for example:

Consulting rooms.

GP surgeries.

Outreach clinics.

There may be a number of routes for requesting/registering an investigation for example:

Paper, for example external/internal post or fax.

Telephone, for example urgent requests.

The important element is to transfer the sample and request, reliably from the requester to the laboratory. At present requests are normally received as a posted package containing the sample and a card giving details of the investigation request. The laboratories publish forms specifically designed for requests (for example a set for different sample types – e.g. Blood,



Amniotic Fluid, Chorionic Villi, Solid Tissue and for specific disease and test types – e.g. Leukemia, FISH and DNA/Molecular tests).

The forms have a common section and a special section appropriate for the specific sample and/or test type.

The common sections must include:

Patient demographics

Requesting clinician details

Details of those people who should receive the test report.

Commissioning and invoice details (e.g. the patient’s Primary Care Trust - PCT).

Reason for requesting the test.

Consent information regarding the use and retention of the sample.

Consent information regarding the use of information.

The specialist sections may include

Additional information about the request, e.g. episode history, pedigree information.

Family history of the associated disease, has a mutation already been found?

Details of the safe preparation, storage and packaging of samples appropriate for the sample type.

All the forms provide advice regarding safe delivery of the sample and request to the laboratory. This includes the full address and contact details of the laboratory.

It is the responsibility of the clinician taking the sample to gain consent for the testing, retention and further use of the sample. The investigation request process should allow consent settings to be passed from the clinician to the laboratory.

Notes At present the requests are, without exception, sent to the laboratories on simple paper forms. Imprecise completion of the forms or use of inappropriate forms or letters means that the requests often lack detail and clarity. The laboratories spend a great deal of time clarifying request details. The laboratories would benefit from a system where complete, accurate and legible details can be passed directly to the receiving laboratory systems. Computerised systems (e.g. NCRS) may help support electronic transfer of test request details.

If electronic requests become available, the laboratory services must ensure that robust processes are developed that ensure the link between the sample and the associated request is retained.

Genetic tests may be carried out on individuals and families. Sample taking may take place in different places at different times. The system should allow a sample taker to notify the laboratory that a sample has been taken and dispatched. The notification should identify the investigation associated with the sample.

To help ensure that appropriate test requests are made, the system may provide decision support, for example a test directory with details of test



time, cost and clinical utility.

NCfH system integration may include:

Details of the test requester may be taken transparently (via the authentication record) from the Care Records Service indexes e.g. the Spine Directory Service).

Details of the test subject(s) may be taken from the Patient Demographics Service.

Investigation details may be derived from the UKGTN test directory.

Request/Sample Receipt

Find or add new patient recordEnter Request and Sample

Information into the database

Independent check and sign offof booking in process (e.g. Duty

Scientist)

Selection of initial testpathw ay including

preparation

Print sample trackinginformation e.g. generate

'lab-sheet', sample label set andbar-codes

Figure 10. Booking in Process

2. Investigation Request and Sample Receipt (Booking In)

Description Receipt of samples and investigation requests may be made by authorised (authenticated) laboratory staff.

The task takes place within the laboratory, usually within a dedicated sample reception area.

This is the first laboratory based process. Incoming investigation requests and samples are booked into the laboratory and details entered into the computer system.

There are two inputs to the process these are:

The investigation request.

The samples to be investigated.

Usually the two elements arrive together, however sometimes investigations



are requested on samples already held at the laboratory (e.g. frozen DNA) and sometimes the samples are collected separately and arrive separately (before or after the request). The staff check for non-matched requests and samples, for example where an investigation request arrives and the associated sample has not arrived within a set timeframe.

The investigation requests are received via:

Paper, for example external/internal post or fax.

Telephone, for example urgent requests.

The paper requests may be on laboratory forms, hospital forms or free text letters.

Figure 10 illustrates the booking-in sub-process. The process ensures that:

The samples are handled correctly, for example checked for damage and processed according to Control of Substances Hazardous to Health Regulations (COSHH).

Complete details of the patient, investigation request and samples are captured in the information system. The information may include:

All request information, this may include data from the request form or letter any supplemental information may be scanned (e.g. pedigree diagrams).

Local and national coding may be applied, for example categorisation of the disease, reason for referral or test request.

Sample information including quantity and quality.

A unique identification number is generated in order to uniquely identify the elements of the investigation request (e.g. request and sample). The number can be simply a local sequential number, however high throughput regional networks require more complex id numbers uniquely identifying the investigation across a region and conforming to agreed standards, e.g. including a laboratory id.

Sample tracking information is produced, for example the lab-sheet, container labels and bar code labels (the sample often travels through the laboratory in a ‘package’ which includes lab-sheets, labelling, work-sheets and notes).

The system information and sample tracking is checked and verified. Some cross checking may be used for example correlation of urgency with referral reason.

The initial testing pathway is defined and the appropriate sample preparation process is selected and the sample is assigned to the correct specialist subgroup or individual.

Most laboratories maintain an independent list of incoming samples and requests in a ‘daybook’. The daybooks purpose is to minimise the opportunities for sample/request loss, it allows minimum delivery logging as samples/requests arrive. The daybook entry contains minimal data entry (e.g. patient name, date of birth and postcode).

Once booking in is complete the sample is passed to the duty scientist responsible for the particular sample/request type, for example DNA, pre-



natal, post-natal, oncology.

Notes The notes associated with 1. Test Request/Sample Collection are also relevant here. Electronic transfer of requests may affect the booking in processes.

If the sample receipt is made distinct from the request, checks and processes to ensure that the samples/requests are reliably matched and alerts are produced concerning outstanding investigation request or sample receipt.

Some systems issue a confirmation to the investigation requester.

3. Sample Distribution

Description Sample distribution is normally carried out by the duty scientist.

The task is carried out within the laboratory.

This process prepares for the test or tests to be carried out on each sample. This step is closely associated with 4. Export and 5. Sample Management.

Distribution may include:

Request acceptance or rejection (back referral). Genetic tests can be complex, time consuming and expensive. Labs report receiving ambiguous and inappropriate test requests and their expert knowledge can sometimes identify a more appropriate test or action. The labs often discuss the request with the requesting clinician to identify the best course of action. This sometimes results in a decision not to carry out tests on the sample.

Divide the sample (e.g. where more than one test will be carried out on a single sample).

Sample storage, for example the request may be simply for retention of a sample with no immediate testing, or a part of the sample may be stored.

Sample export. Specialised tests are partitioned between the laboratories. The sample may require export in its raw form or following some preparation (e.g. DNA extraction).

Notes Some LIMS are able to map investigations to tests, and tests to procedures; the system knows the procedures that constitute a test and can instruct the technician what aliquots are needed and where they must be sent.

4. Test Export

Description The decision to export a test is normally taken by the duty scientist as part of the distribution step. The task is closely associated with 3. Distribution and Preparation and 5. Sample Management

The task takes place within the laboratory.

Sample export is much more common in molecular genetics than cytogenetics.

A common scenario for export is:



Investigation request and sample booked in.

Sample has DNA extracted and banked.

A scientist prepares a complete, accurate investigation request.

A DNA aliquot and the investigation request is sent to the receiving laboratory.

The receiving laboratory performs the investigation and reports directly to the requesting clinician and copies the report to the exporting laboratory.

Occasionally the specialist tests demand specialised sample preparation, this means the raw sample must be exported, rather than extracted DNA.

Notes Regional high throughput networks are very keen to exchange details of exported and imported tests in electronic form. NCfH communication infrastructure may help support this.

5. Sample Management

Description Sample management may be carried out by any authorised member of laboratory staff.

The task takes place within the laboratory.

This step is closely associated with 3. Distribution and Preparation. Sample management includes:

Sample inventory, what and where samples are.

Sample storage monitoring, e.g. fluctuations in freezer temperature.

Safe sample disposal.

Management of control samples.

Notes Increasing audit requirements (for example the Human Tissue Act 2004) may require support for ‘chain of custody’ information for certain samples.

6. Analysis/Verification

Description This stage is concerned with the actual testing of the samples - the detail differs between cytogenetics and molecular genetics.

The testing may be carried out by any authorised member of laboratory staff (scientist or technician). An individual is allocated responsibility for a procedure or test.

The task is undertaken within the laboratory. In general a test consists of a number of procedures which produce results. The procedures are managed by worksheets which include fields for:

Details of the sample(s), patient(s), responsible scientist(s), and procedure/information verifiers.

The name of the procedure(s).

The results of the procedure(s).

Verification results (sometimes this is an inspection and check of the



results, sometimes a blind reproduction of the procedure).

Procedure management information, for example details and signed double checks when samples (aliquots) are transferred between vessels.

Notes regarding the progress of the procedures.

Worksheets are prepared on the computer, printed, filled in by hand during the procedure, results are keyed back into the worksheet on the computer.

The nature of worksheets vary depending upon the procedures ,from simple sheets associated with a single sample, to very complex sheets describing batches by test or by patient. The current generation of genetic LIMS have weak worksheet support. Many molecular laboratories have produced independently managed spreadsheets which make it very difficult for results to be captured in the LIMS.

In cytogenetics procedures tend to deal with a single sample and there is little batching. Cytogenetic scientists are on the whole happy with the current worksheet support. However robots are being introduced which can batch some of the preparatory procedures (e.g. harvesting) this may demand better worksheet support.

In molecular services the use of high-throughput systems and larger plates (e.g. 96/384 well) means that worksheet requirements are getting more complex.

In both cytogenetics and molecular genetics initial sample preparation is often common across many different tests and so the process is batched before specialist processes begin. For example in molecular genetics an initial DNA extraction is performed and in cytogenetics the sample is cultured and harvested. Sample preparation is dependent upon the sample type, quality, quantity and the investigation/tests to be performed. The responsible scientist confirms the detail of the preparation steps. The preparation consists of a number of procedures controlled by worksheets.

Notes Genetic laboratory systems need improved worksheet support to include:

Flexible worksheets that can accommodate different combinations of procedure, for example:

Multiple procedures on a single patient.

Single procedures on multiple patients.

Multiple procedures on multiple patients.

Inclusion of control samples.

Support for worksheet configuration. For example the system knows the pending samples and procedures. It should produce worksheets that combine scheduling (by priority) and efficient batching.

The ability for a scientist to change a system generated worksheet.

The ability to capture complex results, e.g. a table or aggregate type (at present most accept only a simple text string or a number).

The ability to capture test result double check by independent scientist (for example confirmation/check of result or second blind test).



Capture of process details, for example aliquot transfer checks.

Automatic field derivation, for example calculations based on entered values.

Integration with machines and instrumentation. Worksheet configurations should be passed electronically to instruments and results passed automatically back to the LIMS.

7. Results Reporting and Sign Off

Description Results Reporting is normally carried out by the scientist with responsibility for the investigation. Only a small defined set of senior laboratory staff (e.g. the director and deputy) may sign off completed reports. The senior staff member may return the report for further work before sign-off (a loop).

The task is carried out within the laboratory, however better electronic support means the task could be carried out remotely.

This element has two main phases:

Report preparation, the results of the tests/procedures are collated, interpreted and reports prepared.

Report verification, the report is checked by a senior member of staff before issue to the requesting clinician, checking includes:

Case handled correctly according to investigation request.

Laboratory test data verified.

Laboratory test data reconciled against the patient demographic details.

Computer record is complete and accurate.

Report contents check (e.g. sensible conclusions and recommendations).

Reports normally conform to local laboratory standards which normally conform to national/international standards (for example from the European Molecular Genetics Quality Network (EMQN) and Clinical Molecular Genetics Society (CMGS)). The reports are produced through the population of templates with standard text relating to the nature of the investigation, tests and procedures.

A typical report consists of:

Details of the referral (e.g. patient details, referrer details and information about the referral).

Details of the tests performed and the results.

Results summary, interpretation and conclusion.

Recommendations.

Implications (e.g. for individual and/or other family members).

Further information (e.g. background, sources of further information).

Signature of responsible scientist or technician.



Signature of authorising scientist.

Reports may contain graphics for example pedigree diagrams, test result charts.

In some LIMS, once reports are issued the records associated with it are locked. Senior users may unlock the records and a new or updated report issued.

At present reports are delivered on paper and sometimes by telephone (followed by paper report). Potential routes for delivery include:

Print and post.

Direct fax (to registered ‘safe haven’ fax machines).

Email (e.g. attached PDF).

Secure web based delivery.

Delivery through clinical applications, e.g. the national patient record system.

Copies of issued reports are held on paper in the patient records, the service would like to archive an electronic version (e.g. PDF).

Notes Increased electronic support means that analysis and interpretation could be carried out remotely from the laboratory (remote working can help provide better personnel support and in turn improve staff recruitment and retention).

To ensure integrity of issued reports a digitally signed electronic copy of the report, e.g. a PDF file, could be archived.

8. Laboratory Management

Description General laboratory management tasks may be carried out by any authorised member of staff.

The tasks are carried out within the laboratory.

This supports the general management of the laboratory, for example to help conform to Clinical Pathology Accreditation (CPA) standards, it includes:

Document Control (e.g. configuration and access control of Standard Operating Procedures – SOP and policy documents).

Control of Substances Harmful to Health (COSHH) information management.

Equipment inventory.

Staff records.

Audit control (e.g. internal policies that need review).

Reporting, local activity reporting and submission to regional and national data collection (e.g. NEQAS, CMGS/UKGTN).

Commissioning, contract and invoice details (e.g. management of exported and imported sample processing).



9. Network Management

Description Network management may be carried out by authorised staff within laboratory and by network management staff for example the staff of UKGTN.

The tasks may be carried out within laboratories and network management offices.

There are a number of levels of laboratory networks operating in the UK. Most of these are concerned with the introduction of high throughput techniques and the sharing of specialist tests for efficient and fair coverage. At a national level Molecular Genetics have the UKGTN and regional networks are exchanging samples for specialist or high-throughput testing.

The networks require high level management that includes:

Routing of samples and investigation/test requests through the network.

Exchange of a dataset describing an exported/imported sample.

Activity reporting across the network.

At present most network management is achieved using paper based processes (although network activity reporting uses spreadsheet delivery). In some areas that have homogenous LIMS, electronic exchange of information is being tested.

Notes The datasets necessary for network management must be defined before detailed exchange mechanisms can be developed.



Section 1-8 Entities within Genetic Laboratory Information Systems

175 It is vital that Genetic laboratory information systems adequately represent all the entities associated with a genetic investigation, and allow all the potential relationships between them to be created and clearly displayed to users. Many existing solutions fail in this respect, a good example is provided by pre-natal testing where laboratory staff create a new record for an unborn child with the name ‘Baby (or Foetus) of Smith’, the text string providing the only link with the mother’s record. The practice does not create a formal database link and cannot adequately support database functions such as reporting.

176 This section discusses the entities and relationships necessary to genetic laboratory systems that have been identified in the consultation exercise. Figure 11 illustrates the model and the table that follows it contains some explanatory notes.

Person

Investigation

Sample

Test Test Result

Report Amended Report

Family

Multiple

One

1

1 Note referenceProcedure Procedure Result

2

3

Figure 11. Laboratory Entities and Relationships

Note ID Note 1 In pre-natal testing the subject of the investigation will normally be the unborn

child, but the record must clearly identify the record as being prenatal and link to the mother, father and index case.

2 In some laboratories a request may produce a number of reports, for example follow-up or summary reports are written to summarise work done on several members of a family over a long period of time.

An increased focus on confidentiality and consent has led some laboratories to restrict reports to be associated with a single individual. In addition they may not allow multiple reports against a single request, updates and revisions are always captured as amended reports.



3 Many laboratories produce summary reports which describe the findings and implications across a whole family.

177 This document uses terminology to differentiate between important entities within genetic information systems as shown in Table 3.

Table 3. Terminology

Term Definition Investigation A request for testing sent by a clinician to the laboratory. Often known

as a sample referral or a sample test request.

Sample The physical material for investigation. Synonymous with specimen.

Test A countable, measurable unit of work (for charging, quality and performance measuring). For example, microdeletion investigations (DiGeorge, Miller-Dieker and Kallman syndromes) may consist of a conventional cytogenetics test plus targeted FISH tests, or molecular analyses where mutation screening by techniques such as heteroduplex analysis is followed-up by direct sequencing

Procedure A process that results in a single result. An ‘atomic’ process to the information system. Sometimes referred to as an assay. For example a cytogenetic examination produces an ISCN expressed karyotype. The results may be complex, but are tangible and can be expressed in a way that may be captured in a database (e.g. a character string, a number, an image, a table or an aggregate type).

A test may have a single procedure associated with it, for example a FISH test may often consist of a single kit based procedure.

178 A clinician sends a request for an Investigation with the appropriate samples. The Investigation is made up of one or more Tests. To complete a test a number of procedures must be completed, each procedure produces results which contribute to the overall test result, interpretation and investigation report.

179 This model allows the information system to capture the relationships between investigations, samples, tests and procedures which in turn provide support for workflow, decision support, comprehensive reporting and progress tracking.

180 At present test or operation results are not consistently captured in the laboratory database (note that we mean results of distinct operations not reports, for example a karyotype or a gene mutation test – found/not found). Results are not captured in the databases because:

The systems do not provide the structures adequate to represent them, for example worksheets often provide a single text string which cannot capture the result of a multiple gene mutation test.

The systems provide little benefit from results capture, for example automatic selection for inclusion in reports.

181 In addition to the result of the tests the test operation creates ‘process information’ for example images and numerical analysis data. The process information is not necessary for production of the test report but is vital if the report is questioned and the results must be



checked. So, test and procedure information can be classified into two: result and process, this is illustrated and described below.

The result. A set of information describing the result of the test. This is the ‘output’ of a test and should include all the information needed by the test requester (e.g. the scientist who will interpret and report the test findings). The result should be kept instantly available in the information system.

Test process information. Information created during the test procedures that may be required later, for example to check the validity of a result, to audit test procedures or check the materials and the quality controls. It may include detailed subtest results, instrument outputs. The test process information may be kept available in the information system for a limited time but may be archived later.

Test orProcedure

Request

Result

Process Information

182 Process information is often kept in paper records or where instruments are used, in separate unlinked databases. It is vital that electronic systems integrate instruments and provide links to all necessary process records.



1.8.1.2 The Anatomy of a Report 183 Current information systems do provide support for

creating reports suitable for delivery to investigation requesters. Although the content and style varies across the genetics community the consultation identified a general form which is illustrated on the right.

184 The report contains details of the patient (or family), the investigation requester, the commissioner, details of the request (e.g. reason for referral, disease, test requested), details of the actual tests carried out, the results of the tests (some laboratories do not include actual results), an interpretation of the results tailored to the knowledge level of the requester and recommendations, for example further tests on this individual or other family members.

185 The interpretation is often a block of standard text for example “No mutation found”, “Normal Male”. Many systems allow the scientist to classify the results, offering a selection of common result types; this in turn selects the standard text. Standard interpretations may be edited. It also offers an open classification where the scientist creates a unique interpretation. The interpretation may be long and include diagrams (e.g. a pedigree diagram) and graphics.

Demographics Details of the patient, the requester

the laboratory and the commissioner.

Results The test results

Interpretation The scientist’s interpretation of the

results

Recommendations The scientist’s recommendation for

further action

Investigation request Details of the request, reason, tests

performed, dates.

A Report Structure

Traceability Signatures of responsible and

authorising scientists.



Requirements



Section 1-9 Introduction

186 This section presents the requirements gathered through discussion with the management and staff of regional genetic centres. The requirements have a simple numbering system: common requirements (applicable to clinical and laboratory genetics) begin RU, clinical requirements begin RC and laboratory requirements begin RL. Each major section (common, clinical and laboratory) begins numbering from 1.

The requirements are presented in tabular form illustrated in Table 4. The table provides a reference number, and a description of the requirement. The priority column is provided in order for localisation of the OBS. Every requirement is termed ‘must have’, genetic centres employing the OBS must allocate their own priorities according to local need, for example allocate 5 to an essential function, allocate 0 for not required.

Table 4. Requirement Table Example

Ref Requirement Priority RU10 Access Control. The system must provide robust role based

authentication.

RU11 Access Control. The system must provide default ‘built-in’ role based access control based at minimum on password access.



Section 1-10 Common Requirements

Overall System Requirements

187 As well as effectively managing the workload of genetic centres, it is vital that systems are friendly, secure and responsive. This section outlines requirements that must underpin both clinical and laboratory genetic information systems.

188 Many of these requirements are non-functional and very difficult to quantify appropriately. Correspondence to the requirements should be judged through qualitative comparison including testing with realistic datasets.

Integrated Working

189 Clinical and Laboratory information systems are logically separate and must be available as distinct applications. However the components must be capable of close integration within genetic centres and support cross-disciplinary working with associated specialities.

Ref Requirement Priority RU1 The system must support independent implementation of either the

Clinical component or the Laboratory component as a stand-alone application.

RU2 The system must support close integration of clinical and laboratory applications by way of information exchange, for example Clinical application export of test requests and import of test results, and vice-versa for laboratory apps.

RU3 The system must provide the ability to record investigation requests and outcomes across disciplines, e.g. pathology, haematology, medical imaging, neurology, biochemistry etc.

User Experience

Ref Requirement Priority RU4 The system interface must be intuitive and attractive (for example use

standard operating system resources and keep up with the developing interface models).

RU5 The system must be responsive to user requests, with minimal waits for information access and update.

RU6 The system must correspond to the language and models of care employed by geneticists.

RU7 The system must provide comprehensive search facilities able to help users locate any type of system entity, e.g. by diagnosis, clinic date, locations, responsible clinician etc.

RU8 The system must warn about suspect information entry for example inappropriate dates or diagnoses.



RU9 The system must present information in appropriate graphical forms, for example pedigree diagrams.

RU10 Changes to data or relationships in any view type must update the information store in a consistent manner.

RU11 Graphic interfaces must provide the ability to edit each object’s linked information sets (properties, relationships and datasets).

RU12 Graphic interfaces must provide the ability to select elements for operations (e.g. select family members to call to an appointment).

RU13 The system must provide both sortable ‘datasheet’ lists of multiple records and ‘form’ views of single records, with easy switching between ‘summary’ and ‘detail’ views.

RU14 The system must provide for easily navigable hierarchies of entities represented by the system. For example to view test results from different tests on a single individual, or the same test(s) on related individuals.

RU15 The system must provide suitable defaults wherever possible and appropriate: examples include the current system date - with or without an offset as appropriate.

RU16 All default data values must be configurable by the system administrator.

RU17 The system must enforce consistency of input, for example by mandating required fields, allowing the user to ‘pick’ from limited ranges of options, validating input etc.

RU18 The system must provide ‘undo’ or ‘cancel’ functionality to roll-back or to cancel data modifications made in error wherever this is practical.

RU19 The system must explicitly confirm to the user by message box or status line message that data has been modified, or the modification cancelled, in accordance with the user’s instructions.

RU20 Error messages should be self-explanatory and where possible should give some indication of the remedial action required.

System Security

Genetic investigations may compile sensitive information about an individual or family, it is vital that it is held securely and informed consent concerning its use and sharing is recorded and respected.

System and Information Security

Ref Requirement Priority RU21 The system must provide effective security of the system resources.

For example use of reliable and proven operating system and database security mechanisms.

RU22 Elements of the system exposed to public networks (e.g. the Internet) must be protected. For example allow modular installation on networks protected by firewalls (perimeter security).

RU23 Any communications passing through public networks must be encrypted using an appropriate standard, e.g. 128 bit Secure Sockets Layer (SSL).

RU24 The system must provide the facility to manage standard security certificates.



RU25 The system must provide the facility to digitally sign any outgoing communications (for example investigation reports).

RU26 The system must provide the facility to accept and verify digitally signed communications (for example investigation requests or referrals).

RU27 The system must provide internal mechanisms to ensure that updates cannot be made by two users simultaneously.

RU28 The system must be able to transfer data between different modules with integrity and security.

Role Based Access Control

Ref Requirement Priority RU29 The system must provide robust role based authentication. RU30 The system must provide default ‘built-in’ role based access control

based at minimum on password access.

RU31 Password control must be based on good security practice including: RU32 Password control must enforce minimum password length and

complexity (i.e. letter/numeric combinations)

RU33 Password control must enforce periodic password change RU34 Password control must limit the number of log-on attempts with

invalid password.

RU35 Password control must mask the display of password on screen. RU36 Password control must encrypt stored passwords. RU37 The system must support the ability to link to external security

products for example commercial access control applications and NHS standard mechanisms provided by NCfH.

RU38 The system must support full role based access control, locally configurable for groups and individuals.

RU39 The system must support role based access to system functionality (e.g. menus, forms, operations).

RU40 The system must support role based access to information sets and data fields.

RU41 The system must be delivered with a full default set of appropriate roles.

RU42 The system must allow the set of roles to be managed locally for example, allow users to map permissions to roles, add new roles and remove existing roles.

RU43 The system must provide an automatic log-off facility after an administrator defined period of inactivity, without affecting system integrity.

RU44 The system must support the use of national or international standard security policies and resources. For example, conform to those defined by NCfH in the English NHS.



Audit Trails

Ref Requirement Priority RU45 The system must retain a full history of clinical information. For

example once clinical data is ‘committed’ it must be retained in full, any changes must be held separately with a record of the user responsible for the update and the time it was made.

RU46 The system must maintain full audit trails of activity including system access and any change to information.

RU47 The system must maintain a full, searchable log of changes to information including when and by whom.

RU48 The system must maintain a full, searchable log of access and use of the system.

System Management, Modifiability and Support

Genetics is a fast moving speciality. Systems must be capable of revision and extension without the need for complete replacement.

Ref Requirement Priority RU49 The system must provide a full data backup and recovery scheme,

including any necessary database backup agents for on-line backup of open databases.

RU50 The system must enforce referential integrity to prohibit removal of primary entities where dependent entities exist.

RU51 The system must provide a means to log requests for correction by the system administrator of data entry errors which are not correctable through the user interface. For example, deletion of duplicate sample entries.

RU52 The system must implement an error logging facility capable of recording detailed troubleshooting and / or debugging information for system administrators and / or developers. Ideally this would be inactive by default to reduce processing overhead, but capable of being switched on by the system administrator for specific troubleshooting.

RU53 The system must provide support for legacy data import. RU54 Systems must be extensible and capable of revision without the need

for complete replacement. New functionality must integrate appropriately into the existing application. For example through user defined forms and macros and full Application Programming Interfaces (API).

RU55 The system must allow existing datasets to be extended RU56 The system must allow new datasets to be defined, managed and

accessed.

RU57 The system must allow new functions and operations on existing and user defined information to be defined.

RU58 Extensions and amendments to the system must be robustly managed, through appropriate version and configuration control mechanisms. For example new forms must be explicitly released before they are available to users.



RU59 Long-term information retention. Detail of past generations is very important to the analysis of genetic conditions of current patients. Details of past patients must be retained in accessible forms. Methods of managing this ever increasing store without impacting the responsiveness of the system must be provided.

RU60 The system must provide a test database where operation will not impact normal running of the laboratory or affect laboratory data. Use of the test database will include developing/testing system updates, demonstrations and training.

RU61 Comprehensive training and training materials must be available, suitable for delivery by the system vendors and suitably trained customers.

RU62 Training must include user training suitable for clinical and administrative staff.

RU63 Training must include developer/system manager training for in-house support of the IT systems.

RU64 Comprehensive support services must be available. RU65 Support services must include user support for working hours (e.g. via

telephone, email or internet chat).

RU66 Support services must include support resources including user manuals, online help and regularly updated internet support pages.

RU67 Support services must include community user groups supported through web pages and message boards

RU68 Support services must include technical documentation including logical data maps with column name and type information and referential dependencies.

RU69 Support services must include implementation and development services, for example: installation and system commissioning services; integration with existing systems; customisation, for example additional dataset management forms; and specialised module development.

Information Management and Coding

Use of coded information (from look up tables or drop down lists) allows computers to query, compare and collate information. It also allows decision support software to make decisions based on data values.

System entities and relationships

Ref Requirement Priority RU70 The system must support all the “concepts” commonly employed

within genetics, these elements will have data sets associated with them, relations between them and support analysis and reporting. Concepts include: genetic centre staff and roles; referrer; patient; family; appointment; sample; investigation; test; procedure; result and report.

RU71 The system must allow locally defined elements to be added. RU72 Each element must have a default dataset associated with it and must

provide the ability to extend the dataset.



Coding

Ref Requirement Priority RU73 The system must allow the use of specialist genetic code sets

including Online Mendelian Inheritance in Man (OMIM).

RU74 The system must support links to genome browsers such as ENSEMBL (www.ensembl.org).

RU75 The system must support the use of standard clinical code sets e.g. SNOMED-CT (mandated in England by NCfH), ICD-10, OPCS and HRGs.

RU76 The system must support administrative code sets such as those employed in Payments by Results and Choose and Book in the English NHS.

RU77 The system must support the use of standard genetic nomenclature for example ISCN for describing karyotypes.

RU78 The system must support the use of local and national service code sets and identifiers. For example: staff codes; hospital codes; PCT codes; clinician codes; national patient identifiers (NHS Number); service codes (e.g. the UKGTN test directory); U.S. billing service codes; genetic service provider identifiers (e.g. UKGTN membership) and NCfH Choose and Book Service identification codes (corresponding to the Directory of Services).

RU79 The system must provide the ability to define local code sets RU80 The system must provide the ability to extend standard codes sets

with local codes

User defined data sets

Ref Requirement Priority RU81 The system must support the addition and management of user

defined datasets.

RU82 The system must provide the ability to define new datasets. RU83 The system must provide the ability to add components able to

manage user defined datasets for example forms able to collect the dataset and reports including the datasets.

RU84 User defined data must be available anywhere system defined data is, for example data exports and reports.

Family relationships

Ref Requirement Priority RU85 The system must support the capture and management of

sophisticated family relationships, including pedigree identifiers and relationships including: family (pedigree) identifier; mother and father; unborn children; siblings; relations through existing and planned pregnancies; and index/proband case.

RU86 The system must support comprehensive support for unborn children and their relationships including: foetus records linked to mother and father; details of pregnancies including multiple pregnancies; surrogacy; donors (e.g. sperm/oocytes); and capture of outcome (i.e. birth) information.



RU87 The system must provide or closely integrate with pedigree visualisation applications.

RU88 Changes made to pedigree diagrams must be reflected in the patient records and vice-versa.

RU89 The system must provide pedigree version control (e.g. audited changes).

RU90 Pedigree coding must be compatible with linkage and other types of pedigree analysis programs.

Confidentiality and Consent

190 Patients must give consent for the use and sharing of information and samples. The responsibility for gaining consent will lie with referring clinicians (e.g. clinical genetic consultants and counsellors) who have direct contact with patients. Laboratory systems must log the given consents and information access and sharing must be governed by the patients consent settings. Consent must become an important part of the investigation request dataset

Ref Requirement Priority RU91 The system must log patient consents and use the information to

govern information access and sharing.

RU92 The system must provide the ability to follow the ‘chain of responsibility’ for information and specimens through their lifetime from collection to destruction (consent tracking).



Section 1-11 Requirements of Clinical Genetics

General Requirements

191 This section contains the overall system requirements for clinical genetic services.

Users and Roles

Ref Requirement Priority RC1 The system must include a comprehensive default set of appropriate

roles. For example: Clinical Geneticists who increasingly may have subspecialty expertise (for example consultants, specialist registrars and doctors in training); Genetic Counsellors (sometimes referred to as specialist genetic nurses, genetic associates or genetic co-workers); Administrative and clerical staff; and System Administrators.

RC2 The system must enforce role based access. Procedures and tasks must be allocated to role sets and their use restricted to the roles in that set. Role based access must include appropriate viewing of information for example prohibiting administrative staff from viewing clinical information.

RC3 The system must hold security information for each database element, allowing flexible allocation of access rights (e.g. create, read and write access) by role or individual identity.

RC4 The system must allow local role management allowing creation of roles and allocation of default resource rights.

RC5 The system must track responsibility for investigations, procedures and tasks to a role and an individual.

System Availability

192 Genetic centres have large regional catchment areas. All centres run remote clinics at district hospitals and primary care facilities. Some centres have specialist staff permanently employed in remote settings.

Ref Requirement Priority RC6 The system must be available 24 hours a day, 7 days a week with

pre-arranged downtime for maintenance.

RC7 The system must be available to users wherever appropriate both within the genetics centre and outside it.

RC8 The system must be available within the specialist genetics centre. At the point of care (e.g. clinics and treatment rooms) and remote from the point of care (e.g. offices, meeting rooms, nursing stations).



RC9 The system must be available at temporary and permanent outreach specialist genetic centres at the point of care and remote from the point of care.

RC10 The system must be available via secure remote access outside specialist genetic centres, for example at ward or hospital department consultations.

RC11 Remote Access: The system must provide authenticated secure, encrypted access from outside the genetics centre, for example from authorised home offices.

Consent

193 General consent issues are included in the common requirements. The clinical system must be responsible for capturing consent.

Ref Requirement Priority RC12 The system must provide the ability to capture patient consent. The

Joint Committee on Medical Genetics are shortly to release guidance on consent issues, previous guidance called for consent: to treat, examine or care; for a test to be performed; for information to be held at the genetics centre; for information to be shared with parties outside the genetics centre; for the storing, sharing and re-testing of specimens; to share information across family groups; and for the storage and sharing of images.

RC13 The system must provide links to information describing consent suitable for informing patients.

Patient Contact Support

194 This section concerns support for the day to day management of the clinical genetics centre including patient and family indexes, referral management and clinic management.

Patient and Family Records

Ref Requirement Priority RC14 The system must support a comprehensive patient demographic

dataset (e.g. NHS Number, name, address, contacts, date of birth, GP, ethnic group).

RC15 The system must allow details of individuals that have not been formally referred to be entered into the system. The non-referred status must be clearly indicated on the record.

RC16 The system must allow information to be recorded at the family level, i.e. provide a family record as well as a patient record.

RC17 Family records must allow multiple diagnoses to be recorded. RC18 The system must allow families to be sub-grouped. RC19 The system must allow family groupings to be re-arranged, for

example split or merged and any changes logged.

RC20 The system must provide full commissioning details (e.g. contract, invoicing and payment details).



RC21 The system must provide family relationship table support (family membership, proband, mother, father) and support for records of unborn children.

RC22 The system must allow local extension of patient and family records through free-text and coded fields.

RC23 The system must allow multi-media files to be stored in the patient/family record, for example pictures and diagrams, and provide embedded viewers.

RC24 The system must allow files of any type to be attached to the patient/family record.

RC25 The system must pre-fill fields whenever possible by using information held locally and through an ability to link to other resources, for example postcode databases.

RC26 The system must interface with national or regional resources to help definitively identify referenced entities (e.g. people, organisations and locations). These may include services such as the NHS National Strategic Tracing Service (NSTS) or the new Personal Demographics Service (PDS) for patient identifiers including NHS numbers. The English NCfH is introducing many national resources including patient and staff indexes.

RC27 The system must allow the recording of any special needs for the patients or family, for example translator or hospital transport necessary.

Dealing with Enquiries

195 Genetic centres deal with a large number of public and patient enquiries. Dealing with enquiries effectively means access to patient, family, condition, disease and general information.

Ref Requirement Priority RC28 The system must provide efficient access to patient, family, condition,

disease and general information. For example common responses (e.g. frequently asked questions) and access to information sheets.

RC29 The system must provide enquiry tracking and management, for example recording advice given, complaints, monitoring and reporting on enquiry status and maintaining lists of tasks and their status.

Referral Management

196 Support for the receipt and processing of patient referrals.

Ref Requirement Priority RC30 The system must manage the complete referral lifecycle from receipt

to episode closure.

RC31 The system must monitor and report on the status of referrals corresponding to national standards where they exist, for example received, reviewed, and allocated.

RC32 The system must capture the date and time of all events and changes of status.



RC33 The system must allow referrals to be allocated to clinicians (their owner). It must maintain the allocation and report where referrals are not allocated.

RC34 The system must allow referrals to be sub-allocated to individuals or groups, for example an owning consultant allocates to a counsellor for family analysis.

RC35 The system must maintain a list of clinicians involved in the referral (consultants, counsellors and nurses).

RC36 The system must present lists of active referrals to their owners. RC37 The system must support full capture of referral details including

details of: the patient; reasons for referral; coded referral classification; urgency; details of the referring clinician, and the commissioner (e.g. PCT).

RC38 The system must capture an image of the referral letter or form. RC39 The system must provide full support for electronic receipt of referrals

where they are available, for example in the English NCfH’s Choose and Book programme.

RC40 The system must provide compliance to the English NHS Choose and Book programme.

RC41 The system must support the electronic exchange of additional detailed investigation information where it is defined in an accepted standard. For example, pedigree information.

RC42 The system must allow details of pre-referral and post-referral genetic risks to be assigned to an individual, for example prior risk of familial cancer based on family history.

RC43 The system must provide links to code sets for classification of referral information, for example OMIM and SNOMED-CT.

RC44 The system must provide comprehensive search facilities to help staff find existing patient details associated with new referrals.

RC45 The system must interface with national or regional resources to help definitively identify referenced entities (e.g. people, organisations and locations). These may include services such as the NHS National Strategic Tracing Service (NSTS) for patient identifiers including NHS numbers. The English NCfH is introducing many national resources including patient and staff indexes.

RC46 The system must support the production of receipts for referrals. RC47 The system must support the production and issue of electronic

referral receipts where they are defined in an accepted standard

RC48 The system must support the production and issue of paper referral receipts for posting.

RC49 The system must monitor the lists of received referrals and produce alerts when they are not acted upon within locally set timeframes.

RC50 The system must manage the production, distribution and tracking of standard pre-clinic letters and forms (for example family history questionnaire).

RC51 The system must provide summary reports of patient and family information suitable for use at clinical review meetings.

RC52 The system must capture the action selected for the referral, for example discharge, call for an appointment or home visit.



Clinic Management

197 Full support for clinic set-up, patient booking, on-the-day clinic operation and follow up action and correspondence.

Ref Requirement Priority RC53 The system must provide full clinic template management. RC54 Clinic template management must include user defined clinic

templates (locations, times, slots, personnel)

RC55 Clinic template management must include support for multi-disciplinary team clinics.

RC56 Clinic template management must include family clinic support, i.e. multiple patients at a single appointment.

RC57 Clinic template management must include specialist clinic support (e.g. multiple invited attendees by condition).

RC58 Clinic template management must include open access/walk in clinic support, e.g. Tay-Sachs clinic.

RC59 Clinic template management must support detailed service descriptions, for example as demanded by NCfH Choose and Book directory of services.

RC60 Clinic template management must manage detailed clinic information that may be used to inform patients (e.g. pre-clinic questionnaires, patient information).

RC61 The system must allow appointment slots to be linked, for example where appointments are for linked activities (e.g. tests before a clinic appointment).

RC62 The system must support flexible clinic formats for example allow variable appointment lengths.

RC63 The system must provide appointment management (support for the scheduling and allocation of clinic slots.

RC64 Appointment management must include allocation of appointments supported by referral/patient details.

RC65 Appointment management must include access/waiting list policy support (access to policy, support through referral data values).

RC66 Appointment management must include management of provisional bookings.

RC67 Appointment management must include batch or individual creation, printing and distribution of clinic appointment letters.

RC68 Appointment management must include patient contact management and tracking (e.g. letters and information issue, telephone reminders).

RC69 Appointment management must include management and tracking of appointment changes.

RC70 Appointment management must include management of appointments outside the clinical setting, e.g. on the ward or at the patients home.

RC71 The system must identify special dates for example public holidays and issue warnings if appointments are scheduled on those days.

RC72 The system must provide comprehensive clinic management (support for the preparation and on the day administration of the clinics).



RC73 Clinic management must include patient/family notes tracking, e.g. a notes management function allowing check in/out of notes, logging who has the notes and where.

RC74 Clinic management must include support for barcode printing and reading for notes tracking.

RC75 Clinic management must provide a full set of clinic appointment lists (e.g. by clinic, location, doctor, counsellor, record ids).

RC76 Clinic management must record comprehensive clinic information, e.g. attendance or non-attendance, clinicians seen.

RC77 Clinic management must record comprehensive appointment outcome information (coded and free text), e.g. diagnoses, actions.

RC78 Clinic management must allow follow-up actions to be recorded and tracked.

RC79 Management of follow-up and review (ensuring actions resulting from patient contact can be tracked and are completed).

RC80 The system must provide methods of tracking actions, action ownership, progress and patient response.

RC81 The system must prevent users contacting patients logged as deceased.

RC82 The system must support the rescheduling of appointments either individually or in batches taking account of any linked activities and resources.

Clinical Support

198 This section deals with support for the clinical processes, including clinical information management (text and image) and links with other services and specialists.

Family Investigation Support

199 Often, the first task of a genetic investigation is to build a complete picture of the family history, this benefits from access to regional and national registers, for example cancer registries and cause of death information.

200 The details of this element are covered in the common requirements which can be summarised as:

Visualisation of family relationships (e.g. pedigree diagrams).

Synchronisation between database information and visual representations (e.g. updates to pedigree diagram automatically reflected in database and vice-versa).

Graphical user interface based upon family tree representation (e.g. select individuals for appointments from family tree).



Ref Requirement Priority RC83 The system must provide the ability to link family members across

genetic centres (e.g. via explicit links or information exchange data).

RC84 The system must provide links to regional/national and international medical registers, for example cancer registries.

Clinical Record Keeping

201 Support for electronic capture of clinical information including free text notes, correspondence and coded information.

Ref Requirement Priority RC85 The system must provide full support for the production distribution

and tracking of clinical correspondence.

RC86 The system must support the cataloguing and tracking of letters (e.g. letters to patient, GP, referring clinician and letters of referral).

RC87 The system must support document scanning, storing indexing and retrieval.

RC88 The system must provide a user extensible library of standard templates, for example patient assessment and result reports.

RC89 The system must provide support for specialist information collection. RC90 The system must provide a method of recording an individual’s

dysmorphic features following an examination.

RC91 The system must provide support for collection of additional, disorder specific information (e.g. Muscular Dystrophy; Cleft Group).

RC92 The system must provide support for the definition of local information collection templates.

RC93 The system must provide the ability to import and export information collection templates.

RC94 The system must provide the ability to import and export collected information sets.

RC95 The system must provide the ability to import and export anonymised collected information sets for research purposes.

RC96 The system must provide full image management support. RC97 The system must provide full image capture support. RC98 The system must provide full support for the review, coding and

classification of images (e.g. save images with metadata).

RC99 The system must provide a clinical image enquiry system able to search on image metadata and linked patient records.

RC100 The system must support full integration with hospital image systems (PACS) (e.g. ECG, X-Ray, Ultrasound).

RC101 The system must support the production of longitudinal views of patient and family care.

RC102 The system must allow the capture and coding of complaints, incidents and near misses.



Long Term Patient Management

202 Support for long term patient and family care, including scheduled events, unscheduled events, multi-disciplinary care and surveillance/screening.

Ref Requirement Priority RC103 The system must provide comprehensive support for notifications and

alerting.

RC104 Notification support must include date based alerts, e.g. review case in 2021.

RC105 Notification support must include event based alerts, e.g. review at age 16.

RC106 Notification support must include recurring events, e.g. review every 5 years.

RC107 Notification support must include group alerts, e.g. recall a set of patients due to a new test or technique becoming available.

RC108 Time based alerts and notifications must have no restriction on available dates in the future.

RC109 Notification support must provide the ability for users to assign notifications and alerts to individuals, groups or roles.

RC110 The system must provide support for multi-disciplinary care for example defining and tracking care actions such as attendance at clinics.

RC111 The system must support the management of call and recall for surveillance and screening. For example help select the individuals to call and track their progress through the programme.

RC112 The system must maintain a list of patient DNA sample banked with laboratories.

RC113 The system must support cohort management for research, for example help clinicians identify suitable candidates, compile datasets and track progress through the programme.

Decision Support

203 Computer support for care. Providing the ability to manage and monitor clinical (and administrative) processes.

Ref Requirement Priority RC114 The system must use information held in the database to help select

appropriate actions, for example highlight the most appropriate clinic based on coded referral data.

RC115 The system must provide comprehensive support for worklists. RC116 Worklist support must include the ability to manually allocate tasks to

individuals, roles or groups.

RC117 Worklist support must maintain lists of know tasks for individuals, roles or groups, for example: lists of outstanding results; lists of patients due for follow up; and clinic schedules.



Access to Information

204 Access to general information, for example the ability to share useful documents and web references across a genetics centre or specialist subgroup within it.

Ref Requirement Priority RC118 The system must provide access to specialist information resources,

for example via shared lists of online genetic resources.

RC119 The system must provide access to locally managed information resources, e.g. management of local controlled documents including forms, policies and procedures.

RC120 The system must provide online access to journals and publications.

Management and Reporting

205 Support for standard report sets and locally defined reports to support audit, monitoring and reporting of activity by centre, disease, specialist groups and individual.

Ref Requirement Priority RC121 The system must provide a comprehensive flexible reporting system

which allows users to define their own reports and data exports with access to all objects in the database including system and locally added entities.

RC122 The system must allow users to create ad-hoc reports, and save the report definition without adding it to a system report library.

RC123 The system must provide a regularly updated data-warehouse where reports and exports may be performed without impact on the live database.

RC124 The system must provide a comprehensive set of standard reports (report library) for example: new patients; active care episodes; clinic appointments (new, follow-up); waiting times; non-attendance; workload, activity by clinician, specialist group, commisining PCT, clinic type and venue; performance monitoring against national and local targets; cases outside targets (e.g. waiting times); and complaints, incidents, near misses

RC125 The system must provide a comprehensive set of commissioning reports including: Summary reports showing overall centre activity; and statements for individual commissioners.

RC126 The system must provide commissioning reports compatible with the English NHS Payment by Results initiative.

RC127 The system must allow users to define reports that compare activity with targets and highlight areas where performance is falling short of defined thresholds. For example reports that support achievement of the 18 week from referral to treatment target.

RC128 The system must allow locally defined reports to be added to the standard report library.

RC129 The system must allow the users to develop their own views on the database, including new links and relationships between entities.



RC130 The system must prepare data exports suitable for standard genetic output and performance reporting. For example Hospital Episode Statistics (HES) and waiting times (nhs.uk).

RC131 The system must prepare data exports suitable for audit and registries for example: cancer Registries; disorder specific databases (e.g. Muscular Dystrophy and Cleft Group); and national audit – e.g. screening programmes.

RC132 The systems must provide flexible data export support, for example: data export files (e.g. spreadsheet, CSV or XML files); messaging systems (e.g. HL7); database integration (e.g. SQL/ODBC interfaces); and Application Programming Interfaces (API).

RC133 The system must provide an NCRS compliant HL7 v3 data interface.

Integrated Clinical Support

206 The ability to link to other electronic resources for example electronic referrals, requests for investigations and results reporting. This cannot be provided by the genetic information system alone but via the systems taking a full part in national developments such as the English NCfH.

Ref Requirement Priority RC134 The system must support access and contribution to electronic health

records where they are available (e.g. through NHS CRS).

RC135 The system must support electronic requests for investigations and assessments.

RC136 The system must support electronic access to results of investigations and assessments, for example pathology and genetic test results.

RC137 The system must support linkage to (or copies of) associated information for example clinical correspondence with other professionals involved in cross disciplinary care.

RC138 The system must support electronic referral to other specialists for example through integration with NHS electronic booking.

RC139 The system must provide access to clinical images (e.g. PACS integration).

RC140 The system must provide access to national clinical databases (e.g. cancer registries).

RC141 The system must support genetic centre integration, e.g. controlled information sharing with local genetic laboratory services.

RC142 The system must provide electronic support for common transactions agreed with integrated laboratory facilities, for example where a specialised test is required, a request for sample export, (with supporting information) to a genetics laboratory offering the test.



Section 1-12 Requirements of Laboratory Genetics

General Requirements

207 This section contains the general requirements for laboratory genetics.

Users and Roles

Ref Requirement Priority RL1 System roles must include those appropriate to functions in the

laboratory for example: report authorisation; report creation and update; investigation management; investigation distribution; patient demographics management; and information system administrator.

RL2 The system must hold security information for each database element, allowing flexible allocation of access rights (e.g. create, read and write access) by role or individual identity.

RL3 The system must allow local role management allowing creation of roles and allocation of default resource rights.

RL4 The system must enforce role based access. Investigations, procedures and tasks must be allocated to role sets and their use restricted to the roles in that set.

RL5 The system must track responsibility for investigations, procedures and tasks to one or more roles and individuals.

RL6 The system must provide a mechanism to identify investigations, procedures and tasks performed by trainees under supervision, and to identify the supervisor responsible.

RL7 The system must support configurable operational policies regarding results checking and / or authorisation of reports, including the ability to stipulate more than one checker / authoriser, and enforce these by requiring role-based authenticated check-stamping prior to report release.

LA1. System Availability

Ref Requirement Priority RL8 The system must be available 24 hours a day, 7 days a week with

pre-arranged downtime for maintenance.

RL9 Local Access: The system must be available anywhere within the specialist genetics centre including: on a single site and on multiple, geographically remote sites.



RL10 Remote Access: The system must provide authenticated secure, encrypted access from outside the genetics centre, for example from home offices.

Service User Interface

These requirements describe the interface presented to service users (e.g. clinicians requesting investigations). The points of interaction are:

Investigation request.

Investigation progress reporting and alerts.

Results report delivery and access.

In some areas national protocols and mechanisms are being developed to provide standard electronic access to services, for example NCfH in the English NHS.

Investigation requests

Ref Requirement Priority RL11 The system must provide support for capturing ‘offline’ paper based

investigation requests.

RL12 The system must allow local users to create master request forms containing all the necessary information fields and include free text fields.

RL13 Request forms must be suitable for printing and for download, for example from the laboratory website.

RL14 The system must provide support for accepting secure online investigation requests.

RL15 The system must present a directory of available laboratory services that includes comprehensive descriptions of the services and provide guidance for requesting clinicians

RL16 The system must allow information to be attached to requests for example photographs and pedigree diagrams.

RL17 The system must provide decision support (protocols) to requesting clinicians helping them to request appropriate services and ensure any pre-requisites are fulfilled (e.g. a biochemical confirmation of diagnosis).

Progress reporting and alerts

Ref Requirement Priority RL18 The system must be capable of presenting progress information in

response to service user queries.

RL19 Progress reporting must include internal status reports to laboratory staff (for example to aid in response to telephone enquiries).

RL20 Progress reporting must include secure online access to progress



status direct to service users. RL21 The system must support service user alerts when requests cannot be

fulfilled within timeframes. For example when samples associated with investigation requests are damaged or not received.

RL22 Alerting support must include internal alerts to laboratory staff. RL23 Alerting support must include alerts direct to service users. RL24 The system must preserve the requesters request identifier (e.g. that

allocated by the requesters system or a national/regional system) and allow online access using that identifier.

Results reporting

Ref Requirement Priority RL25 The system must support electronic delivery of reports. RL26 The system must support secure electronic delivery (for example via

email).

RL27 The system must support secure authenticated online access to reports.

LA2. National investigation request and reporting protocols

Ref Requirement Priority RL28 The system must be compatible with appropriate national investigation

request, tracking/tracing and reporting protocols. For example those provided by NCfH in England.

Investigation Management

This section present the requirements associated with the day to day management of genetic investigations, from booking-in samples to producing reports.

Booking In

Ref Requirement Priority RL29 The system must provide an ‘electronic daybook’ to allow immediate

capture of incoming investigations (including arrived samples and requests) with minimal information (e.g. patient name, date of birth and postcode).

RL30 The system must support full capture of investigation details including details of: the patient; the sample; the investigation; the investigation requester; the investigation commissioner; the report recipients.



RL31 The system must be capable of recording ‘core’ or ‘generic’ details pertaining to all instances of any class of entity within the system and also details which are specific to a particular type. For example, all specimens should include information about dates of collection and receipt, quantity and quality etc but for prenatal samples gestational age at the time of sampling and serum screening risk are important details, whereas for haematological specimens parameters such as total and differential cell-counts are important.

RL32 The system must be capable of identifying and notifying the user of potentially duplicated data entry (e.g. substantive matches in key properties) and offering the options of assigning as new, assigning to an existing record, changing an existing record or aborting as appropriate in context.

RL33 The system must maintain a directory of available tests and associated information (e.g. workload units).

RL34 The system must identify ‘imported investigation requests’ from other genetic laboratories.

RL35 The system must be able to assign an incoming referral with appropriate commissioning details by, for example, associating the patient’s home postcode or the referring hospital with the appropriate commissioning body.

RL36 The system must support private commissioners operating outside the NHS.

RL37 The system must support the electronic exchange of additional detailed investigation information where it is defined in an accepted standard. For example, pedigree information associated with linkage investigations.

RL38 The system must allow further work and results (for example a new investigation) to be added against banked samples.

RL39 The system must accept prioritised investigation screening request lists from authorised clinicians.

RL40 The system must provide comprehensive search facilities to help staff find existing details associated with new investigation requests e.g. patient details, banked samples.

RL41 The system must interface with national or regional resources to help definitively identify referenced entities (e.g. people, organisations and locations). These may include services such as the NHS National Strategic Tracing Service (NSTS) for patient identifiers including NHS numbers. The English NCfH is introducing many national resources including patient and staff indexes.

RL42 The system must provide flexible identifier allocation. RL43 The system must provide the ability to locally allocate unique

identifiers.

RL44 The system must provide the ability to interface to regional, national or international identifier allocation systems (for example within regional genetic testing networks and international consortia such as the European Skeletal Dysplasia Network (ESDN)).

RL45 The system must produce appropriate label sets for physical tracking of sample packages around the laboratory. For example name, date of birth and sample number.

RL46 The system must interface to traditional and emerging sample tracking technologies for example the printing and reading of bar-codes or the integration of Radio Frequency Identification (RFID) technology.



RL47 The system must support the production of receipts for received requests and samples.

RL48 The system must support the production and issue of electronic receipts where they are defined in an accepted standard

RL49 The system must support the production and issue of paper receipts for posting.

RL50 The system must monitor the lists of received investigation requests and produce alerts when investigation requests are found to be incomplete (for example missing samples) or are not acted upon within locally set timeframes.

RL51 The system must allow for ‘Call Off’ i.e. a formal cessation of processing and ‘signing off’ before the requested investigations are complete in situations where subsequent information not available at the time of referral or request indicates that a particular course of investigation is no longer appropriate. Investigations or processing incomplete because of ‘Call Off’ must be clearly differentiated from those which are incomplete but ongoing.

Investigation Export

Ref Requirement Priority RL52 The system must support the preparation of export test requests. RL53 The system must support the preparation of electronic investigation

requests where it is defined in an accepted standard.

RL54 The system must support the preparation and printing of paper investigation requests.

RL55 The system must support the preparation of comprehensive export worklists where multiple samples are to be exported.

RL56 The system must provide the ability to capture and report the status of exported investigation requests (e.g. issued, received and fulfilled).

RL57 The system must alert selected users when exported investigation requests fail to report in a defined timeframe.

RL58 The system must capture reports resulting from exported investigation and link the report to the request.

Workflow and Worklists

Ref Requirement Priority RL59 The system must support worklists – the ability to manually allocate

investigations, tests and procedures to individuals, roles or groups.

RL60 The system must support workflow – the ability to pre-define investigation pathways for the system to manage. Following selection of an investigation pathway, the system must automatically allocate tests and procedures and place them in appropriate worklists. The system may tell the technicians what aliquots are needed and how much material must go in each one.

RL61 The system must be capable of supporting changes to the investigation path in response to intermediate test results.



RL62 The system must provide links to online versions of Standard Operating Procedure documents.

Tracking and Tracing

Ref Requirement Priority RL63 LIMS systems must be capable of recording and reporting a set of

nationally defined checkpoints. The set emerging from this study are: ‘Registration’ the clinician (or exporting laboratory) has registered the test request with the laboratory service; ‘Sample in transit’ where centralised test registration is in place, the laboratory would benefit from confirmation that a sample has been dispatched; ‘Booking in’ the laboratory has safely received a sample; ‘Exported’ the test request and sample (or its derivative) has been exported to another laboratory (responsibility now passes to the importing laboratory and the process finishes); ‘Test Activation’ all information and samples associated with a test request have been received and testing may commence; ‘Test Begun’ the test process is underway; ‘Test Finished’ the test process is complete; and ‘Report Issued’ the analysis and interpretation phase is complete and the report has been issued.

RL64 The system should support tests that require more than one sample. For example, they should maintain a list of samples expected against a test request and indicate when all expected samples have been successfully received.

RL65 The system must highlight statuses that are outside set thresholds, for example if expected samples fail to arrive within a defined timeframe. Highlighting methods must include: alerts, for example emails to defined users or groups; reports, providing lists of items with status outside thresholds.

RL66 The system must provide a measure of progress against test/investigation tariff and provide facilities to report this locally and to any national track and trace service through defined message sets.

RL67 The system must provide a flexible comprehensive method of defining and reporting on more detailed checkpoints as defined by the laboratory system users.

RL68 The system must provide comprehensive sample inventory management (e.g. DNA samples, cell suspensions and cell lines).

RL69 The sample inventory management must include sample location. RL70 The sample inventory management must include the history of the

sample (including amount used/remaining).

RL71 The sample inventory management must include the condition of samples (e.g. storage temperature monitoring).

Worksheet Support and Instrument Integration

208 This section describes worksheet configuration and the exchange of information between the information system and instruments.



Worksheet Support

Ref Requirement Priority RL72 The system must provide comprehensive and flexible worksheet support

that can accommodate different configurations including: multiple procedures on a single patient; single procedures on multiple patients; multiple procedures on multiple patients; inclusion of variable control formats; and replicate testing.

RL73 The system must allow the capture of complex results within the worksheet, e.g. a number, text string, table or aggregate type (at present most accept only a simple text string or a number).

RL74 The system must allow capture and attachment of external files to worksheets at the worksheet or result level. For example gel images or instrument output files.

RL75 The system must provide automatic worksheet configuration. For example the LIMS knows the pending samples and procedures. It should produce worksheets that combine scheduling (by priority) and efficient batching.

RL76 The system must allow a scientist to change a system generated worksheet

RL77 The system must provide the ability to capture multiple test result checks by an independent scientist (for example confirmation/check of result or second blind test result).

RL78 The system must support logging of process acts, for example defined aliquot transfer checks.

RL79 The worksheets must support automatic field derivation, for example calculations based on entered values.

RL80 System worksheets such as Gel, multiwell plate and multispot FISH slide worksheets must support ‘blank’ and ‘control’ wells / plates / spots.

RL81 The system must provide a ‘randomisation’ tool for allocating samples and controls to multiwell plates and arrays etc. to ensure effective distribution across the plate.

RL82 The system must allow creation of repeat / new worksheets by copying – with a new name – an existing worksheet.

RL83 Molecular worksheets must be capable of handling multiplex PCR results. RL84 The system must provide full support for formal ISCN and HGVS

nomenclature of complex cytogenetic and molecular results by way of accepting extremely variable length strings and permitting the full use of alphanumeric characters and those allocated special meaning in the nomenclature (e.g. ; :: , [ ] ( ) + - > ?)

RL85 The system must provide a mechanism to ‘wrap’ lengthy and complex karyotype strings onto multiple lines with ‘sensible’ breaks - normally after commas or close brackets

RL86 The system must provide for optional display of cell numbers – enclosed within square brackets – within the karyotype.

RL87 The system must provide a means of recording ‘raw’ FISH data such as probe colour spot counts and fusions / splits per metaphase as well as the interpreted karyotype in formal ISCN nomenclature.

RL88 The system must provide a multicounter ‘mouse-click’ counter tool.



Instrument/LIMS Integration

Ref Requirement Priority RL89 The system must provide support for the integration of laboratory

instrumentation, machines, robots and specialised Laboratory Information Systems (LIMS). For example Worksheet configurations should be passed electronically to instruments and results passed automatically back.

RL90 The systems must provide flexible integration support, for example: data import/export files (e.g. spreadsheet, CSV or XML files); messaging systems (e.g. XML or HL7); database integration (e.g. SQL/ODBC interfaces); and Application Programming Interfaces (API) (e.g. script languages such as JavaScript/VBScript or lower level languages such as C, C++, C#, VBA or Java).

RL91 The system must be capable of interfacing to specialist Laboratory Information Systems (LIMS) in addition to direct instrument integration. For example where multiple instruments are managed by a workflow based LIMS in a high throughput facility.

RL92 The system must be able to capture selected instrument process output for example images and test process information, and index it against the investigation.

RL93 Worksheets must be capable of scaling with instrument demands, currently 96 well plates are commonplace but 384 and 1536 wells are available.

Analysis

Ref Requirement Priority RL94 The system must provide convenient access to all the information

directly associated with the investigation, for example test results and process information.

RL95 The system must provide access to information indirectly associated with the investigation for example results of relevant tests in other departments (e.g. biochemical or histopathology).

RL96 The system must provide integration support for local applications or web based tools.

RL97 The system must integrate with analytical tools for example pedigree visualisation and analysis programs.

RL98 The system must provide access to decision support resources such as the Winter-Baraitser Dysmorphology Database (WBDD, Previously Known as the London Dysmorphology Database), OMIM, PUBMED and Ensembl.

RL99 The system must provide access to electronic patient records where they are available. For example integration with local, regional or national electronic records such as those promised by the English NCfH.

RL100 The system must provide support for External QA (e.g. NEQAS) activity including external image analysis support and sharing. The system must be capable of exporting pseudonymised records including process information for QA, and reimporting it and attaching QA results to the appropriate patient.



Investigation Reporting

Ref Requirement Priority RL101 The system must provide a comprehensive set of report templates. RL102 The system must allow the users to define new report templates from

scratch or based on existing reports.

RL103 The system must allow the users to customise report templates. RL104 The system must select an appropriate report template based on the

investigation, but allow the user to override the selection.

RL105 The system must allow reports to be automatically populated with any entities from the database. For example inserting details of the patient demographics, the referring clinician’s demographics, the reason for request, the tests performed and the results.

RL106 The system must allow the user to classify the investigation result and automatically populate the report template with appropriate text where it has been defined.

RL107 The system must allow the users to define standard text to be included in reports.

RL108 The system must allow any of the automatic system selections to be overridden by the user.

RL109 The system must allow the report to contain rich and complex descriptions including text, diagrams and graphics.

RL110 The system must allow reports to combine the results of multiple investigations, for example, report on investigations across family members.

RL111 The system must robustly support the ‘sign off’ status of reports, for example preliminary, checked and authorised. Reports must be forced to follow the defined sign off pathway and any unauthorised access logged.

RL112 The system must extend the role based access mechanisms to prevent access to unauthorised reports. For example where the system is shared with clinical colleagues they should be prevented from viewing an unauthorised report.

RL113 The system must protect authorised reports from subsequent unauthorised alteration through an explicit and audited lock and unlock mechanism.

RL114 The system must capture an image of the report issued to the requester.

RL115 The system must support multiple report delivery routes including: print and post; direct fax to ‘save haven’ fax machines; email (e.g. attached PDF); web based delivery; through nationally defined results reporting mechanisms, for example in England the NCRS; and other electronic formats (for example XML) where schemas have been defined

RL116 The system must encrypt reports for electronic delivery. RL117 Electronic report delivery must be capable of supporting digital

signatures (e.g. private/public key between laboratory and requesting clinician).

RL118 The system must log any report issue and reissue, and the delivery mechanism including phone messages.



RL119 The system must provide the facility to generate forms requesting follow-up information at the time of report generation and for onward transmission of these forms with the relevant report.

RL120 The system must provide the facility to record user-defined ‘follow-up’ information requested at the time of issue of report.

Laboratory Management and Reporting

209 This section is concerned with the management of the laboratory and the prodiction of management reports (for example performance reporting).

Reporting and Information Export

Ref Requirement Priority RL121 The system must provide a comprehensive flexible reporting system

which allows users to define their own reports and data exports with access to all objects in the database including system and locally added entities.

RL122 The system must provide a locally managed report library accommodating standard system defined reports and locally defined reports.

RL123 The system must allow individual users or groups to define report library views.

RL124 The system must enforce role-based access rights to protect reports from unauthorised access.

RL125 The system must allow users to create ad-hoc reports, and save the report definition without adding it to a system report library.

RL126 The system must provide a regularly updated data-warehouse where reports and exports may be performed without impact on the live database.

RL127 The system must provide a comprehensive set of standard reports (report library) including: management reports (including performance, for example investigation requests received, requests accepted/rejected, samples received, samples processed, reports issued, investigation numbers by type etc); workload unit reports; time based reports, for example investigation end-to-end timings and distinct test/procedure times; incomplete work; work incomplete within turnaround time; tracking and tracing status reports; out of threshold track and trace status reports; and performance against defined targets including the targets set by the genetics White Paper.

RL128 The system must provide a comprehensive set of commissioning reports including: summary reports showing overall laboratory activity; statements for individual commissioners; invoices suitable for issue to commissioners; and invoice tracking reports (issued, paid).

RL129 The system must allow locally defined reports to be added to the standard report library.

RL130 The system must allow the users to develop their own views on the database, including new links and relationships between entities.



RL131 The system must prepare data exports suitable for standard genetic output and performance reporting. For example those managed by CMGS, UKGTN, UK NEQAS, specialist commissioners and regional testing networks.

RL132 The system must prepare data exports suitable for registries and local/national/international consortia for example: cancer registries; disorder specific databases (e.g. Muscular Dystrophy and Cleft Group); and the European Skeletal Dysplasia Network (ESDN).

RL133 The system must support user-definable local resource lists – eg FISH probe and cell-line databases – and provide functionality for update of these by direct import from on-line web-resources.

RL134 The systems must provide flexible data export support, for example: data export files (e.g. spreadsheet, CSV or XML files); messaging systems (e.g. XML or HL7); database integration (e.g. SQL/ODBC interfaces); and Application Programming Interfaces (API).

RL135 The system must provide an NCRS complaint HL7 v3 data interface.

Laboratory Management

Ref Requirement Priority RL136 The system must support consumables management including:

inventory management (amount, location, batch, expiry date); monitor use of materials (DNA samples, kits, reagents, probes); monitor the condition of materials, e.g. fridge temperature monitoring and alerts; alert laboratory staff when inventory items require re-order; track ordered items; and log batches used in procedures.

RL137 The system must provide a laboratory equipment inventory including functionality to maintain a record of past, and schedule for future, maintenance.

RL138 The system must manage and provide easy access to controlled documents, for example: Control of Substances Hazardous to Health (COSHH) information; contracts; and Clinical Pathology Accreditation (CPA) information

Network Integration

Ref Requirement Priority RL139 The system must support national and regional information standards

where they are available, for example the ability to exchange agreed message sets for investigation request, tracking and reporting.

RL140 The system must provide methods for integrating with national and regional resources, for example staff and patient index systems.

RL141 The system must support national and regional activity reporting and audit standards, for example the ability to export comprehensive audit datasets.

RL142 The system must support general national health standards for example integrate fully into national IT programmes such as the English NCfH.



Conclusions and Recommendations



Section 1-13 Conclusion

210 The consultation found a great deal of consensus within the genetics community regarding the requirements of information systems, however it emphasised the findings of the survey (“Analysis and Options Appraisal for Information Management of Systems in Genetics”, NGRL Manchester 2004) showing information system support to be inconsistent across the regional genetic centres. Some centres are very happy, and some very unhappy with systems. The OBS has attempted to present a set of requirements that will help all regional centres procure systems that provide an acceptable level of support for carrying out their activities.

211 In addition to an improvement in support for the internal activities of genetic centres there are pressures for change and improvement coming from outside the community, for example the targets set in the genetics White Paper and the NHS national programmes for improvement to IT especially apparent in the English NPfIT. Key to achieving these improvements is support for better operation as a network at the regional and national level. Systems must support information exchange according to national and locally defined standards. The genetics community must come together to define the necessary standards and ensure they are aligned with national NHS standards.

212 Another important requirement for laboratory genetics is the support for the integration of high-throughput instruments and better management of the workflow through the investigation pathway. These requirements highlighted an important distinction between the information system used in genetic laboratories and traditional Laboratory Information Systems (LIMS). Genetic systems are used primarily to manage information about patients and families, and supporting the production of investigation reports, they have sophisticated demographic support. Traditional LIMS focus on the sample; they integrate instruments and closely manage the test workflow. The next generation of genetic laboratory systems must combine this functionality.

213 The consultation has identified a need for the community to work together to achieve the network operations essential for the development and growth of genetic services, for example development and adoption of regional and national standards. The following recommendations are intended to support coherent community working.

1.13.2 Recommendations

1.13.2.1 Convene a Responsible Body and Adopt Regional and National Standards

214 Identify or create a body able and willing to take responsibility for operational standards for the genetics community, for example produce information standards, develop general requirements (e.g. the OBS), and commission detailed studies where knowledge needs combining or developing.

215 Some immediate tasks are:

Message sets for service users including clinical communications and investigation ordering tracking and reporting. Ensure the message sets provided by national IT programmes (e.g. NCfH) are adequate for genetic services and where they are not modify and extend the set.



Message sets for internal communication, including investigation export/import standards, a representation for exchanging pedigree information and communications with specialist high-throughput facilities.

Adoption of information system standards, for example minimum requirements for information systems to support genetic network operation.

Definition and adoption of national investigation reporting standards.

Definition and adoption of national performance reporting standards.

Development and adoption of track and trace checkpoints for service users and genetic network communication.

Maintain the OBS. An OBS provides a snapshot of requirements which change as demands on the service change. This OBS has been produced at a time of great change for genetic services. The OBS must be extended and refined, and a core set of requirements in support of national network operation identified.

1.13.2.2 Reduce the Diversity of Information Systems 216 Table 5 shows the results of a survey of systems in use in NHS Genetic Centres carried out in

February 2004 ('Analysis and Options Appraisal for Information Management of Systems in Genetics', NGRL (Manchester)/IT Perspectives, April 2004). The table shows the high number of different systems currently employed. In clinical genetics 20 centres employ 13 different systems, in cytogenetic laboratories 17 centres employ 9 different systems and in molecular genetic laboratories 19 centres employ 16 different systems. Many of the systems are in-house developments and in some cases are no longer adequately supported.

Table 5. System in NHS Genetic Centres

Service Total Shire Detente Telepath Genesis In-House

Clinical Genetics 20 8 n/a n/a 1 11

Cytogenetics Laboratory 17 9 0 1 1 6

Molecular Laboratory 19 5 1 1 1 12

217 This fragmented approach to procurement is very common in the NHS and leads to significant disadvantages, for example:

Small local procurements of specialised systems can be expensive.

Low user base often means expensive or inadequate support.

New or extended functionality has limited overall effect and must be duplicated in all the different systems.

Standard communication protocols and mechanisms are difficult and expensive to implement.

Operational compliance with national systems (e.g. NCfH) must be implemented separately in every system and costs are duplicated.

218 It is clear that a more cooperative approach to system procurement would provide significant benefit to the genetics community; it would allow improved functions to be procured at reduced cost and support better network operation.



219 The English NPfIT has recognised this and is procuring a small number of systems on a national basis. The genetics community should work together on system procurement, focussing on a small number of applications (2 or 3) to be used across all centres. This OBS provides a firm base to begin rationalisation of the systems currently in use.

1.13.2.3 Support the IT Steering Group 220 2005 has seen the beginning of regular meetings of the Laboratory Genetics IT steering

Group (name under review), who share knowledge about issues affecting IT in laboratories. The initial interest has focussed on High-Throughput support and the integration of traditional LIMS into genetic laboratories. The group is able to share best practice and avoid duplication of effort (for example shared product demonstrations). It is likely to help support the procurement of compatible systems.

221 The community should continue support of the group through allowing staff time for preparing and attending meetings and provision of any necessary resource support (e.g. meeting accommodation).

1.13.2.4 Engage with the National Programmes 222 In England the National Programme for IT is already impacting clinical information systems

and resources that may benefit the genetic service being rolled out. It is vital that the genetic community keeps abreast of developments in order to:

Ensure developments within genetic systems are compatible with national requirements.

Genetics plays its part in national service infrastructure, for example electronic booking; ordering and results reporting; and the national patient record.

Genetics makes best use of national, regional and local opportunities for information sharing supporting cross-disciplinary patient care.

Mainstream Genetic Information. The genetics community must engage with the national IT programmes in order to build genetic knowledge into the resources they will provide. For example, include genetic information into clinical decision support systems, provide details of where genetic investigations may be of benefit to patients and provide online guidance about accessing the services.

1.13.2.5 Identify Funding For Compliant Genetic System Development 223 Compliance places heavy demands on system developers and many of the current generation

of genetic information applications would need significant enhancement in order to achieve compliance. The cost of compliant systems is likely to reflect the step change in development and maintenance standards. In addition, the commonly encountered in-house developments are unlikely to achieve compliance unless they are allowed the resources to develop appropriate development, maintenance and support services. The genetics community must consider if the advantages of use of compliant systems is worth the increased costs and if so, where the funding for it can be found.

1.13.2.6 Include Biochemistry and Screening in the OBS 224 Attendees representing Biochemical Genetics and screening at the Genetics OBS Workshop

(09/06/2005 – Nowgen Manchester) were disappointed that their specialities had been considered out of scope. The genetics community should consider extending the OBS to include biochemical testing and screening applications.



Appendix A : Glossary

Term Definition ACC Association of Clinical Cytogeneticists Acute Services Medical and surgical treatment usually provided in a hospital AGNC Association of Genetic Nurses and Counsellors BSHG British Society for Human Genetics NCfH NHS Connecting for Health, the organisation managing the English

NHS’s National Programme for IT (NPfIT). CGH Comparative Genomic Hybridisation CGS Clinical Genetics Society CMGS Clinical Molecular Genetics Society COSHH Control of Substances Hazardous to Health CPA Clinical Pathology Accreditation. NCRS NHS Care Records Service DMuDB Diagnostic Mutation Database Project ESDN European Skeletal Dysplasia Network FISH Fluorescent In-situ Hybridisation HES Hospital Episode Statistics HL7 Health Level Seven IM&T Information Management and Technology IS Information System ISCN International System of (Human) Cytogenetic Nomenclature LIMS Laboratory Information Management System LSP Local Service Provider. Provider engaged by NCfH to provide IT

services at a regional level (England has 5 LSP regions) NASP National Application Service Provider. Provider engaged by NCfH to

provide IT services at a national level. NCRS NHS Care Records Service NEQAS UK National External Quality Assessment Service NGRL National Genetics Reference Laboratory NPfIT National Programme for IT, the English NHS’s project of IT

improvement OBS Output Based Specification OMIM Online Mendelian Inheritance in Man PACS Picture Archive and Communication Systems PCT Primary Care Trust PDS Patient Demographics Service PSIS Personal Spine Information Service RGC Regional Genetics Centre SNOMED-CT Systemised Nomenclature of Medicine – Clinical Terms SUS Secondary Uses Service Tertiary services Care of a highly specialised nature



UKGTN UK Genetic Testing Network WBDD Winter-Baraitser Dysmorphology Database (previously London

Dysmorphology Database). XML Extensible Mark-up Language Investigation A request for testing sent by a clinician to the laboratory. Often

known as a sample referral or a sample test request. Sample The physical material for investigation. Synonymous with specimen. Test A countable, measurable unit of work (for charging, quality and

performance measuring). For example, microdeletion investigations (DiGeorge, Miller-Dieker and Kallman syndromes) may consist of a conventional cytogenetics test plus targeted FISH tests, or molecular analyses where mutation screening by techniques such as heteroduplex analysis is followed-up by direct sequencing

Procedure A process that results in a single result. An ‘atomic’ process to the information system. Sometimes referred to as an assay. For example a cytogenetic examination produces an ISCN expressed karyotype. The results may be complex, but are tangible and can be expressed in a way that may be captured in a database (e.g. a character string, a number, an image, a table or an aggregate type).

Karyotype A representation of an individual's chromosomes arranged in a standard format showing the number, size, and shape of each chromosome type. A karyotype may be described using standard nomenclature, for example ISCN where a normal male is 46XY, and female 46XX.

output based specification

Documents