OBS

ICRS
Output Based Specification
Integrated Care Records Service

Part II - LSP SERVICES
Output Based Specification Second Iteration
FINAL 1.0a
Page 1 of 607
ICRS
Contents Visioning the LSP Services........................................................................................................ 4 101 - User Tools....................................................................................................................... 21 102 - Patient Index ................................................................................................................... 33 103 - Prevention, screening and surveillance ......................................................................... 42 104 - Assessment .................................................................................................................... 60 105 - Integrated Care Pathways and Care Planning .............................................................. 69 106 - Clinical Documentation, including Clinical Noting and Clinical Correspondence.......... 92 107 - Care management........................................................................................................ 100 108 - Scheduling .................................................................................................................... 115 109 - eBooking ....................................................................................................................... 125 110 - Requesting and order communications ....................................................................... 133 111 Results reporting.......................................................................................................... 149 112 - Decision support........................................................................................................... 162 113 Prescribing and pharmacy........................................................................................... 173 114 - Diagnostic and Investigative Services ......................................................................... 198 115 - Digital Imaging including specification for a Picture Archiving and Communications System (PACS) Solution............................................................................................ 253 116 - Document Management ............................................................................................... 340 117 - Financial Payments to Service Providers .................................................................... 353 118 Maternity ...................................................................................................................... 361 119 - Social Care ................................................................................................................... 372 120 - Dental Services............................................................................................................. 379 121 Maintain Patient Details ............................................................................................... 386 122 Emergency\Unscheduled Care ................................................................................... 390 123 - eHealth and Clinical Development ............................................................................... 403 124 Information to support secondary analysis and reporting .............................................. 411 125 Surgical Interventions.................................................................................................. 421 Specific Components ............................................................................................................. 439 FINAL 1.0a Page 2 of 607
ICRS
151 Primary and Community Care ..................................................................................... 439 152 - Number not utilised 153 - Acute Services.............................................................................................................. 449 154 - Ambulance Services ..................................................................................................... 451 160 - National Service Frameworks ...................................................................................... 458 161 - Mental Health................................................................................................................ 467 162 - Diabetes ........................................................................................................................ 496 163 - Cancer .......................................................................................................................... 505 164 - Coronary Heart Disease............................................................................................... 529 165 - Older people ................................................................................................................. 546 166 - Childrens Services ....................................................................................................... 561 167 - Renal services .............................................................................................................. 567 168 - Long Term Conditions .................................................................................................. 571 900 Service Delivery Requirements ................................................................................... 572 910 - Programme and Project Management ......................................................................... 573 920 - Testing and Acceptance............................................................................................... 577 930 - Implementation Services .............................................................................................. 581 940 - Training......................................................................................................................... 585 950 - Design and Development ............................................................................................. 588 960 - Business Change Management ................................................................................... 591 965 - New Systems and Services.......................................................................................... 593 970 - Operational Support ..................................................................................................... 595 975 - Integration and Data Output Services .......................................................................... 598 980 - Legacy Management .................................................................................................... 603 985 - Infrastructure Services.................................................................................................. 605
FINAL 1.0a
Page 3 of 607
ICRS
Visioning the LSP Services

Overview This section of Part II of the OBS provides bidders for LSP roles with an overview of the detailed requirements that follow. It is included to help contextualise and frame bidders' proposed solutions and responses. Each bidder shall respond to each of the requirements in this section, demonstrating: a deep understanding of the requirement; credible solutions and approaches that fulfil the requirements; and commitment to working in partnership with the Authority to deliver the LSP Services.
Similarly, each bidder's response to this section must provide the Authority with an insight into the bidder's offering and demonstrate their ability to deliver the LSP Services. Bidders' attention is drawn to the need to respond to the questions and the requirements which are contained in the bordered tables contained in this section, which essentially require the bidder to undertake a visioning exercise. The Concept of Integrated Care The concept of ICRS is to provide integrated clinical information systems across the whole care continuum. The concept provides a powerful model which can p otentially be applied across all care settings and will support all care professionals and disciplines. ICRS will be integral to delivering the NHS of the future - an NHS that truly puts the patient at the centre of everything that is done. Levels of patient-centric service and an attitude to service delivery will exist that is generally considered to be comparable with the best services available globally. Patients will be better informed about their illness, their general health and well being, and about the services that are available to them. This will enable patients to make informed decisions about their own health and will support choice in how services are delivered and tailored to meet their individual needs. As a result the population as a whole will take more ownership and personal responsibility for their own health and in turn this will ensure more appropriate emphasis is placed on disease/illness prevention and health promotion rather than cure. In future, we will no longer see the emphasis and priority placed on bed-based hospital care. Instead we will observe a far greater proportion of healthcare services being delivered in the local community and patients homes. The expertise and skills of a wider range of Clinicians will be used to deliver healthcare and there will be much more emphasis on team working with Clinicians moving between different settings to deliver the care that is required, rather than asking the patient to travel as is the case at the moment. However, just because care is being delivered in more places and staff are more mobile, does not mean that the care delivered will be more fragmented. In future, healthcare services will be fully integrated across the whole care continuum and the patient will pass seamlessly through the system with controlled and managed hand-offs with information flowing with the patient. ICRS will provide the foundation and bed-rock for integrated care and as a by-product will provide reliable and timely information for research and management. The Role of the LSP There is a large gap between the current and target environment needed to support the ICRS concepts outlined above. For example, todays systems are highly disparate and are largely organisation-based. In addition, todays systems generally fail to support the care delivery at the point of care and lack close integration with the business and clinical processes. Bridging the gap will be done by chosen LSPs working in partnership with the Authority. A. The Role of the LSP Each bidder shall provide an overview that summarises its understanding, commitment, approach and
FINAL 1.0a
Page 4 of 607
ICRS
skilled resources to deliver the LSP Services. In doing this, each bidder shall outline: Full Scope of ICRS (National and Local Elements) Bidders must demonstrate their approach to delivering the full scope of ICRS, which is defined in the diagram and paragraphs below. However, while the scope of delivery will ultimately cover the whole care continuum it is recognised that it is unlikely that integrated solutions exist today that cover this full scope. Thus the service offering that is delivered on day one will not be the same as that which is delivered in subsequent years. LSPs will need to design appropriate solutions which can demonstrate clear advantage to the Authority by presenting a coherent and comprehensive route-map that underpins a controlled development and change management programme deployed across complex and varied settings over a number of years. Bidders must also demonstrate that their approach will deliver a full service with respect to analysis, design, implementation, and running of the full scope of delivery. Therefore, bidders must clearly demonstrate that their offering includes all aspects of full service delivery, and not just those that relate to software solutions. The diagram below illustrates what is meant by full scope. It is important to note that this diagram is for illustrative purposes only and is not a definitive statement of the requirements. ICRS Implementation Service the ICRS NASP is responsible for designing and building these solutions. Once the NDA has accepted them into the LSP Services, the responsibility for implementing them will be with each of the LSPs. As the Spine solutions are relatively passive in nature, much of the implementation work will consist of interfacing local systems to these applications and providing end users with the tools on their desk tops to access them. It is expected that only new systems and robust legacy systems will be linked to the Spine. how its chosen solution supports the concepts of ICRS; the range of skilled and experienced resources that will be made available; its ideas for sharing and managing risk; and its long-term commitment to the Authority and its approach for ensuring solutions are future proof by embracing innovation and change.
FINAL 1.0a
Page 5 of 607
ICRS
Scope of LSP Responsibility

Nationally built by NASPs and locally implemented by LSPs Locally configured and locally implemented by LSPs
Sample Set of Generic Processes
INTEGRATED CARE RECORD SERVICE
NHS Spine Personal Demographic Services
Confidentiality Authentication Order Entry E-prescribing Results Reporting Graphical Analysis
Screening
Ambulatory Care Management
Clinical Correspondence/Summary Domiciliary Care Management Master Patient Index ( eMPI) Clinical Noting Resource scheduling Integrated Care Pathways Clinical Decision Support Image Management Management Information Bed Management E-booking Casenote and Film Tracking Mental Health Act Administration
E-booking
Flexible Toolkit to Support Range of Data and Viewing Requirements
Cardiology Colposcopy
Radiotherapy
Palliative Care
Anaesthesiology
Radiology
Electronic Transfer of prescriptions
Diabetes
Nephrology
Child Health Screening Respite Care Trauma Rehabilitation
Theatres Intensive Care
Pathology Maternity
Old Age Psychiatry Endoscopy
Common Services
Range of Care Settings

Home General Practise NHS Direct Community Nursing Walk-In Centres Community Mental Health Hospital Therapies Acute Diagnostic DTCs Psychiatry (OT/PT) Hospital Departments ACADs Social Care Private Health
Tertiary Care
Ambulance
Prison
Hospices
eBooking the eBooking NASP is responsible for designing and building these services with the NDA performing an acceptance role. Because the solution supports complex business processes, it is by definition more invasive and will require much deeper integration with local systems. The complex interfacing required to support the range of point-t o-point connections required for eBooking will be the responsibility of the LSP. Local ICRS Solutions this is the heart of the ICRS concept, and is where the deep rich clinical functionality and clinical data resides to support the end-to-end process of care delivery across a broad range of settings. These solutions will be functionally rich and will either be provided through new solutions procured from LSPs, through the integration of the legacy systems, or through a combination of new and integrated solutions (whichever of these three routes are demonstrated to be the most robust in both functional and technical aspects). The local ICRS solutions will provide a range of generic functionality that can be deployed easily across multiple care settings. Local tailoring must also be supported through the use of a toolkit that enables appropriately trained users to adapt the system to collect and present data to meet the specific needs of specialities and/or modalities of care. The solutions must be flexible and adaptable to future changes in organisation and service delivery models (e.g., more care being delivered in patients homes and in primary and community care settings and in new settings such as DTCs). B. Full Scope of ICRS Each bidder shall provide an overview of its proposed approach to service delivery for each of the following areas: development of local solutions to interface to the Spine and Person Demographic Services; development of local solutions to interface to eBooking; designing, building, implementing and running ICRS implementation services.
In addition, the bidder must provide a summary showing how all of these elements are integrated into a
FINAL 1.0a
Page 6 of 607
ICRS
solution that is consistent and integrated from an end user and technical architecture perspective.
The section below describes at an overview level the overall scope of ICRS and describes in more detail the concepts and thinking introduced above. Scope and Concept of Local ICRS The diagram above has been drawn to be as inclusive as possible in order to maintain the concept of ICRS as a patient-centred, clinically rich information system that spans the whole care continuum across a wide range of different care settings. Bidders must be able to demonstrate how they will provide solutions and migration paths to a complete solution of this nature. The diagram shows the whole of the local ICRS solution, comprising: support for a set of generic processes; a wide range of care settings; and a flexible user controlled toolkit to collect, process and present data.
These concepts are described in more detail below. Support for a Set of Generic Processes (see Modules 102-120) The diagram shows that ICRS contains a set of generic processes that are applicable across many care settings. It is considered that the vast majority of care delivery can be supported by a set of generic processes that are supplemented with specific processes where required. However, to be successful this approach requires a high level of flexibility and tailoring to accommodate specific needs as described below. For example, the ability to order services or the ability to schedule treatment is broadly the same irrespective of the setting or user. Although, who has access to order what services will differ and will conform to protocol/ICPs and other guidelines that ensure care is being delivered in line with agreed standards. Also, in-patient-based mental health delivery uses many of the same processes as acute in-patient care delivery but needs the ability to support Mental Health Act administration, the Care Programme Approach, and other processes defined as being specific to the delivery of in-patient mental health care. A Wide Range of Care Settings (see Modules 151-160) ICRS solutions must be organisation-independent to allow for the future re-organisation of services with minimal impact on the local ICRS solution. It is recognised, however, that no LSP can deliver these services with any one product at the time of contract award. As a consequence, development work will be required, either to extend the range of functionality offered or to develop deep functional and data integration between separate products. A Flexible User-Controlled Toolkit to Collect, Process and Present Data (see Module 101) The functioning of generic processes across multiple care settings requires an ability to tailor the data items that are collected and the way that information is processed and presented. For example, the data collected to support an assessment will be different for old age psychiatry than for a patient in A&E; however, they should be supported by the same generic process tailored to meet specific needs, incorporating relevant measurements and prompts. It is expected that much of this tailoring will be done centrally at a Cluster level, based on NSFs and clinical best practice, with some tailoring being done at a more local level to recognise specific local needs. The tailoring must be capable of being undertaken easily by clinical analysts with training from the LSPs. The LSP must provide solutions that allow users to define the data items that are collected and must also allow users to flexibly define how data in the system is presented (including clinical notes, flowsheets, worklists, tables, graphs, pictures, diagrams, and images).
FINAL 1.0a
Page 7 of 607
ICRS
C. Scope and Concept of ICRS Each bidder shall describe how it intends to: provide a generic set of processes across the whole continuum of care; support a wide-range of care settings; and provide a flexible toolkit that is capable of being used by trained clinical analysts to configure specific data elements and views.
Each bidder should include in its response examples of how it has done this in the past and how it intends to use its existing and future product sets.
Supporting the Patient Journey To help bidders gain a better understanding of the clinical processes that need to be supported by ICRS solutions, three examples of patient journeys across the care continuum are included. It is important to understand that these are high level and illustrative; and that they are to be used to frame the required visioning exercise only. These patient journeys may seem advanced, but many elements of each of them are already being piloted or are established practice in many parts of the NHS. These have been put together with planned and likely developments in the near future to show how services may develop in the next few years. Scenario 1: James Heart Attack James is a 55 year old man. He suffers central crushing chest pain at home. His wife calls 999. A first responder paramedic arrives within 4 minutes and administers morphine and aspirin, and establishes there are no reasons not to give clotbusting drugs if required. The ambulance arrives within 8 minutes and ECG confirms a heart attack. The paramedic administers thrombolysis. With James consent, the details are phoned ahead to the hospital. The ambulance sets out immediately for the hospital, monitoring James ECG and transmitting it directly to the A&E emergency receiving team along with key details of the history and clinical signs. This allows A&E emergency team to warn the cardiologists that a heart attack patient is on the w in, ay contact the coronary care unit (CCU) for a bed and call up his previous medical record/Patient Record. James is fast tracked as an emergency patient and taken straight to the resuscitation room, where a receiving team including a senior A&E doctor and nurse are waiting. The doctor greets James by name he has already been able to scan through James ICRS health record and seen that he does not have a clinical history of heart problems but is a heavy smoker. In A&E, James is reviewed by the team including the consultant, nurse and junior doctor and, on the advice of the cardiologists, a low molecular weight heparin is given to help continue the work of the clot busting drugs. He is transferred to the CCU. In the CCU, James and his wife are met by the ward sister. Nurses provide the first level of on-call cover in critical care. CCU specialists are available around the clock. They are frequently, but not always, on the ward. Nurses are able to give opioid analgesia using patient group directions.
Enhanced role paramedics
for
Streaming A&E
through
Nurse led services
FINAL 1.0a
Page 8 of 607
ICRS
When James is well enough, he is linked to wireless monitors. This allows him to move around the bed and ward, and use the toilets, without removing ECG leads, etc. When James has a relapse and experiences acute shortness of breath, the CCU specialist nursing staff recognise likely heart failure and the need for emergency assistance. An emergency team arrives within 4 minutes. The team includes: resident consultant (anaesthetist, A&E or general physician) SpR (medicine or A&E), SpR (anaesthetist), senior nurse. James spends 3 more days on the CCU, and is then moved to a general acute ward. James is assessed on the ward by the outreach home care team. His wife is very anxious to have him home, so they agree a care plan in which James will have daily visits from the team after discharge from hospital and keep an eye on him using tele-monitoring facilities. His discharge plan includes medication in line with NSF recommendations to reduce the risk of a further heart attack. When James is at home, he has tele-monitoring equipment which he uses to transmit his ECG, BP and heart rate 3 times a day or if there is any concern about his condition. The results from this monitoring are reviewed by the outreach team. James will receive community cardiac rehabilitation from a multi-disciplinary team. James' principal care at home is given by his wife who had a visit from the outreach team before James discharge to help prepare her for this role. She is given written information and contact numbers for the team. She is told signs to watch out for and when to call for help, as well as being given practical advice about how to improve James diet, and managing the daily medication routine.
Wireless monitoring
Integrated emergency teams
care
Hospital outreach teams integrated community care
Home Telemonitoring
FINAL 1.0a
Page 9 of 607
ICRS
Scenario 2: Managing Joans Chronic Illness and Leg Ulcers Joan is 71 and has had diabetes for 5 years. Joan goes on holiday to Spain with her sister, and while she is there she develops leg ulcers. She visits the local health centre who provide some basic care but suggest she seeks further advice as soon as she returns home. With Joans cons ent, they email her local Primary Care centre to let them know they have seen Joan and give details of the treatment they have given. Joans diabetes care is managed by the specialist diabetes nurse, who runs clinics in her local Primary Care centre. As soon as Joan returns, she arranges to see her nurse at the Primary Care centre. The nurse examines her legs. Using decision support software, she prescribes some first line treatment and dresses the ulcers, and recommends that she should see the specialist GP in diabetes, as she will need tight control of her blood sugar if her ulcer is to heal. The nurse also recommends to Joan that she should have her ulcers looked at by a specialist GP in dermatology. The nurse makes both appointments using the on-the-s pot booking system. In three days time they both have convenient slots available, so Joan can see them both on the same day. Joan sees both specialist GPs at the neighbouring health centre, about a mile away. After receiving Joans consent, the specialist GP in diabetes reviews Joans medical history using the shared ICRS health record, including the results from her visit to the nurse a few days earlier. He makes some changes to her diabetes medication, and also prescribes medication to control her blood pressure. He enters the details on the Patient Record, and sends the prescription to the local pharmacy. Joan moves on to the GP in dermatology, who is able to use the ICRS health record to see the results of Joans consultation with the GP in diabetes. She takes some digital photographs of Joans legs to send up to the dermatologist at the acute hospital for a second opinion on best treatment. She also takes swabs so that she can send pathology results, using near patient testing, at the same time. The dermatologist responds within two days confirming best treatment. The dermatologist recommends that Joan does not need surgery now, but suggests some additions to the management protocol that the specialist nurse will use to treat and watch the development of the ulcers. Based on the dermatologists recommendations, the specialist GP prescribes some anti-inflammatory and dressings for the ulcers, and once again uses an electronic link to send this to the local pharmacy. The pharmacy delivers both her prescriptions to her home later that day. Joan continues to see the specialist diabetes nurse regularly, who both supports Joan as she manages her blood glucose and blood pressure more strictly, and monitors the ulcers, arranging for further specialist advice as necessary. Integrated pharmacy Use of decision support software
Extended support and nursing roles in primary care
On-the-spot booking system
E-prescribing primary care
in
Teleconsulting
FINAL 1.0a
Page 10 of 607
ICRS
Scenario 3: Mohammed Breaks His Leg Mohammed, a 13 year old, falls from his skateboard in the park. He goes home in acute pain. His mother doesnt have a car, so a neighbour drives them to an accident treatment centre (ATC) in the town centre. The emergency nurse practitioner in charge calls up Mohammeds full health record. She sees he has no serious medical problems. She x-rays Mohammeds leg and concludes that surgery may be required. Using a digital-imaging link, the nurse sends the x-ray over to the Acute Trust in the local network, where the orthopaedic registrar looks at the image and confirms the nurses diagnosis of a fracture requiring surgery. She asks the nurse to refer Mohammed to the Acute Trust, and an electronic emergency admission request is sent by the nurse. Mohammed and his mother use hospital transport to get from the ATC to the Acute Trust. When Mohammed arrives, he is sent to the adolescent ward with children of his own age, and his mother is offered a bed for the night. Ward staff call up the full ICRS health record and start the Acute Trust admission log for his stay. The ward is managed and run by non-medical staff at night who can call upon doctors when needed. The out of hours Registrar looks at Mohammed. His hand held computer shows him that an orthopaedic opinion based on the x-ray sent from the ATC confirms that surgery is needed. Ward staff book a theatre slot for the next morning. While waiting for surgery the ward staff prescribe Mohammed pain relief using the Acute Trusts electronic prescribing system, which ensures the right dosage for the boy. Consultants review the pre-op work -up and go through the consent procedure with Mohammed and his mother, offering a translation using the Acute Trusts remote system. The surgical trainee undertakes the procedure, while the consultant observes and advises. A non-medical assistant, with special training, helps with the work. The post-op plan is drawn up by the surgeon, with an analgesic prescription and advice about physiotherapy. His post-op care, including medication, will be managed by the ward nursing team and physiotherapist who agree that Mohammed is ready to go home, with appropriate medication. The ward administrator puts together an electronic discharge summary with advice for follow up care, using the information that has been stored on the Patient Record system during Mohammeds stay. It is e-mailed to Mohammeds GP. Mohammed and his mother are given a paper record along with advice about his care including for his school. Before Mohammed leaves, an out-patient appointment is booked for the following Monday and transport home arranged. Non-medically led discharge under protocol Surgical assistant role in theatre Hospital at night non medical cover Booked care emergency ENP MIU Spine Nurse led
Digital transfer images PACs
of
E prescribing
Integrated care with effective communication
FINAL 1.0a
Page 11 of 607
ICRS
D. Supporting the Patient Journey Each bidder shall state, for each of the three scenarios, which elements of the process can be supported by its current solution set, giving the names of 3-4 leading sites that use these elements of functionality. In addition, each bidder shall state which elements of the process cannot be supported at present and for each state when this functionality is likely to be available.
The Current Systems Environment The way that solutions are rolled out across each Cluster may differ significantly and will be planned and implemented to meet specific local situations. However, it is important to illustrate the starting point and be clear about some of the opportunities that exist. It is clear that radical changes to the system environment must be made in order to meet the business direction and drivers described in the previous section. The diagram below summarises the gap between the current and future environment. Bidders should explain how their offering will meet the following goals: Reduce the systems portfolio it is expected that, by December 2010, there will be a vastly reduced number of systems operating and each of these systems will operate on one version of the software; Provide tighter process and data-integration it is essential that much tighter integration exists in the proposed solutions than is apparent in the legacy systems today, and it must be clear how the level of integration increases year on year as products and product sets develop; Align investment to tomorrows NHS as a result of "Shifting the Balance of Power", an increasing amount of care will be delivered close to the patient. Home-based, primary and community care will have an increasingly important role to play going forward. Although ICRS must address the whole care continuum, special attention needs to be given to improving the current situation in primary and community care and improvements must also be made in the area of delivering home-based care; and Consider full scope solutions must be capable of being deployed across the whole care continuum including prisons, ambulances, NHS Direct, Social Care, hospices, and private healthcare. In some instances, these solutions will be provided using the ICRS solution itself and, in other instances, they will be provided though interfaces to products that exist in these other care settings.
FINAL 1.0a
Page 12 of 607
ICRS
Bridging the Gap

From:
Silo or organisation specific systems Administrative processes support Multiple ways of identifying the patient with limited use of the NHS number 1000s of systems from a large number of different suppliers Many different versions of the same products Acute system focus through PAS and departmental systems Limited strategic use of systems in primary and community No access for patient to their electronic records An ageing legacy environment with many systems needing to be replaced Some beacons where deep clinical functionality is being used and wants to be retained and enhanced Many different technologies and limited adherence to standards Limited information available at PCT or SHA levels and a lack of knowledge in general.
To:
Whole continuum of care supported Clinical support with administration information produced as a by -product Fewer systems integrated in a managed solution set Versions consistent across whole cluster Focus on primary, community and home settings to align with business direction Access for the patient through common interface Modern, reliable and planned refresh of systems Greater equity across the county Strict adherence to standards Rich management information driven from clinical practice with knowledge and clinical decision support common place
E. Bridging the Gap Each bidder shall describe how its approach allows the Authority to "bridge the gap", as illustrated above. In particular, it must describe how its approach reduces the total number of systems in the Authority, provides greater degrees of integration, and allows for controlled migration away from todays silo-based systems environment to one that integrates the whole care continuum.
It is recognised that the range and type of solution required are not currently available within single systems. Therefore, the solutions that are ready for delivery at the time of award of contract will be very different to those that will be deployed in 2010. To the extent that it is not possible to provide a concrete commitment to how an LSP's system portfolio will evolve over this time period, it is essential that the bidder provides details of how they expect this migration to occur, giving full details as to why they have selected their preferred architecture and approach for the local ICRS solutions. It is essential that the Authority does not get locked into fixed solutions that constrain its ability to deliver new models of care and achieve the goals outlined in the various strategic documents described in the previous section. F. Solutions Available at Award of Contract Each bidder shall provide detailed descriptions of the constituent elements of its preferred offering that will be ready for deployment at the time of award of contract. This must be done with reference to the full scope described above and must confirm which elements are fully supported, which are partially supported, and which are not supported at all. Each bidder shall provide a detailed description of why the products have been chosen and describe whether they are interim solutions or long term solutions (e.g., some solutions may be
FINAL 1.0a
Page 13 of 607
ICRS
interim for 2-3 years until more integrated functionality can be provided). If the bidder proposes to use interim solutions, it must describe its approach and rationale for phasing these out in the longer term and describe how it will manage this migration to minimise impact on the end users. Each bidder shall provide details relating to this initial deployment, showing numbers of implementations (worldwide and by national jurisdiction), numbers of users (worldwide and by national jurisdiction) and brief descriptions of the product's pedigree and scope. For each product, each bidder shall describe the amount of effort required to make any changes which are required to ensure that the product meets the requirements specified in this OBS, and provide an estimate of the time when this work would be completed, tested and released for general use. Each bidder shall describe the integration technologies that will be deployed across a Cluster and demonstrate the extent to which it provides data and process integration and provides users with a seamless environment, no matter where the service is accessed. Each bidder shall describe how it can support the NHS' development environments, in which the NHS can build additional functionality, using its proven development tools and techniques. Each bidder shall describe where this has been done before and confirm that the Authority would retain the intellectual property rights in these new developments.
Note: it is recognised that, depending on a bidder's solution, the bidder may choose to describe its approach to support each element individually (acute, GP, community, mental health, etc.); it may choose to link elements (GP and community, acute and mental health in-patient care, etc.) or it may choose to describe larger ranges of scope. Each bidder shall explain how and why it has chosen these groupings.
G. 2006 and 2010 Deployment Each bidder shall provide detailed descriptions of the products it intends to use to cover the full range of services as at January 2006 and January 2010. Details must be provided that clearly show how the product set migrates over time. It should be clear why the various products have been chosen and how new products replace older products in previous deployment. Diagrams and text should be used to articulate the planned migration. Each bidder shall describe in detail how the products will be integrated at each point in time and what process and data integration technology and services will be u sed to provide the whole local solution across the Cluster. Each bidder shall describe in detail how users are presented with a common look and feel irrespective of the underlying solutions. Each bidder shall indicate how users will log-on only once to a common environment and have access to all appropriate LSP Services and National Services. Each bidder shall describe the relationship between the National Services solutions and the LSP Services solutions for ICRS and show how a user seamlessly navigates between them.
Where possible, lessons learnt should be used.
H. Future Proofing and Flexibility Each bidder shall provide an overview of the types of business change it expects to see over the
FINAL 1.0a
Page 14 of 607
ICRS
following 5-7 years and provide evidence that its approach and solution set allows for: new local and national business initiatives to be incorporated; new care processes and evidence-based medicine initiatives to be incorporated; and an open standards and an open systems approach to ensure future interoperability.
The following paragraphs provide more detail about the role of the LSP. It is important to note that the precise detail of what is required will differ within each Cluster and this will be the subject of ITN2 and subsequent negotiations. Architecture and Design One of the fundamental skills that an LSP requires is to be able to architect and design a solution that is fit for its purpose and can scale to the level required across a Cluster (see Part III, Module 740 Volumetrics, Scalability and Extensibility for details of the size and volume of activity within a Cluster). The tasks will include: ensuring there is consistent technical architecture across the whole solution set; ensuring that the architecture is capable of scaling across a Cluster with over 10,000 concurrent users, sub-second response times, and availability of 99.99% uptime; integrating business process design and workflow optimisation within the overall approach; utilising integration technologies to link systems to ensure that there is full integration of the ICRS components as part of the LSP Services and that the LSP Services and the implementation of National Services solutions is provided as a seamless solution to end users; ensuring that systems are conformant to standards specified by the NDA; and assessing the most appropriate technical configuration to provide solutions of the scale and complexity required. I. Architecture and Design Each bidder shall describe the skills and resources that it is proposing to design and architect its ICRS solutions on the scale that is required. Each bidder shall describe: the skills and resources that it would make available to architect and design the whole ICRS solution within a Cluster; how it will migrate to a consistent technical architecture over time and reduce the technologies inherent in its solution set (e.g., porting onto a common technology platform); how it proposes to integrate business process redesign and workflow optimisation in its overall approach to architecture and design, giving examples of where this has been done successfully in the past; and the issues it perceives in linking ICRS solutions, including eBooking, as part of the National Services and the LSP Services.
Each bidder shall indicate how it proposes to deploy solutions across a Cluster whilst guaranteeing response times and availability targets for the number of concurrent users described above. Each bidder shall describe the largest install base implemented to date and describe how it intends to deliver solutions that are fit for purpose at a Cluster level. Each bidder shall describe its technical architecture for the whole local ICRS solution as at award of contract and as at January 2010, showing the major components of the infrastructure, including hardware configuration, database configuration, its proposals to utilise the NHS N3 network, and its proposals to link NHS N3 with the desk top within organisations.
Proof of Concept Local ICRS solutions will need to scale seamlessly to hold the data associated with an estimated 10 million people and be capable of delivering the defined service levels. As part of selecting which application vendors to use in their solution offering it is expected that LSPs will have undertaken a
FINAL 1.0a
Page 15 of 607
ICRS
significant amount of technical due diligence to prove to themselves that the solutions they are putting forward are fit for their purpose. J. Proof of Concept Each bidder shall provide details of the technical due diligence that it has undertaken as part of selecting all of the products that it is proposing as part of its initial offering. This should include work done to test the performance, scalability, and availability of each component of the local ICRS solution.
Strategic Fit and Clarity of Vision The degree of modernisation envisaged in the national targets cannot be achieved without the effective support of information technology being used in new and innovative ways. LSPs must be able to demonstrate that they fully understand the business drivers and targets that ICRS is founded upon and show how their proposed solutions assist in the delivery of new patient centric service models, service improvements and efficiency savings. They must clearly demonstrate how their proposed solutions will bring about radical change and deliver greater qualitative and quantitative return on investment that the Authority is making in information technology. However, technology is only one component and will need to be co-ordinated with process redesign, organisational transformation and improved facilities. The LSP should provide senior resources to work alongside those in the NHS to ensure the proposed solutions deliver the targets and value intended. K. Strategic Fit and Clarity of Vision Each bidder shall describe how it will work alongside senior managers within the Cluster to ensure that the ICRS solution supports the current and future direction of the business. In doing so the bidder must show how it intends to link strategic analysis with the development and implementation of new service delivery models. Each bidder shall show how its approach includes process redesign, technology and innovation, organisational design, and the improved use of facilities.
Implementation It is expected that LSPs will play a major partnership role, alongside Cluster management teams, in the implementation of ICRS. It is envisaged that local ICRS will typically be rolled out across whole care communities, in order that the concepts of patient centric integrated healthcare can be proven. Health communities will differ in size and will be defined at a Cluster level as part of ITN2. However, it is probably useful to think of a care community as similar in size to the old district health authorities. Using the concept of care communities creates an additional and very important structure. The detail of who will do what has not been fully defined and arrangements will differ between Clusters and care communities. Although it is not possible to be definitive about the roles and responsibilities of each party, to improve understanding the following bullets describe at a high level a possible scenario of who will do what during implementation: Cluster Management Board and Team responsible for producing local elements of ITN2. Coordinating Cluster procurement activity to ensure that the solution meets requirements and for overall management and monitoring of local implementations for controlling all ICRS related funds. Define potential roll out strategies and plan how staffing and implementation will be managed. Overall management of the roll out within the Cluster and for performance managing the LSPs. Provide the care community teams and LSP with a point of contact for co-ordination and resolution of issues. Provides link with NPFIT; SHA Advisory Team responsible for undertaking initial analysis of implementation waves and for providing assistance and advice to care community teams as and when required. Making sure that the big-picture and local priorities are kept aligned;
FINAL 1.0a
Page 16 of 607
ICRS
Care Community Team responsible for working with the Cluster management team, LSP and SHA Advisory Team to implement solutions. This will include joint working with the Cluster management team and LSP on all aspects of implementation including change management, project management, benefits realisation, testing, training, and local configuration; and LSP Team described in this and associated OBS documents. In summary, responsible for taking the requirement and for designing and building local solutions. Prime responsibility to implement national and local applications working alongside Cluster management and care community teams on day-to-day implementation issues. Working alongside Cluster teams to coordinate and control the overall shape and success of the local programme. L. Roles and Responsibilities Using its experience of implementing solutions on this scale, each bidder shall describe how it proposes to deploy resources at each of the above levels giving a summary of the main roles and responsibilities.
The way in which solution sets will be rolled out will differ by Cluster because the priorities will be different and the chosen LSP solution set will also be different. When planning implementation a number of factors will need to be taken into account. These include the: national and Ministerial targets; need to prove the concept of ICRS across whole communities; ability to leverage from experience and re-use skills in other places; local business priorities and readiness to accept new solutions and change; ability to roll out generic functionality across whole care communities; design and architecture of the proposed solution and the extent to which it uses integration and interface technologies and who supplies these technologies; extent to which the proposed solution has a standard way of configuration across all elements; degree to which acceptance to standard build and roll out is achieved with users and managers; need to implement deep rich clinical local ICRS applications linked to National ICRS applications; existing systems and the extent to which they are at the end of their useful lives or have some years left in them; the degree to which legacy systems are used and interfaces written and re-written; degree to which point solutions can be implemented across the patch either on an as needed basis or as a wholesale implementation; and amount of parallel implementations that can be done at one time.
It is clear that there is no right solution and that a range of different approaches will need to be taken in parallel. M. Approach to Implementation Each bidder shall show its understanding of the issues by describing its preferred approach for implementing the local product sets across a whole care continuum. Consider the whole solution being rolled out in 3 phases which will be implemented as at December 2004, December 2006, and December 2010. Each bidder shall demonstrate its understanding of implementation as part of the National Services and the LSP Services by describing how it proposes to phase the implementation across 3 phases, ensuring that those in phase-3 received benefits in the short-term. Each bidder shall provide estimates of the total number of people it would expect to be involved within a Cluster to implement its proposed solution as at award of contract using a range of key roles (e.g., programme management, change management, clinical analyst, interface development first and second line support). For each role, the bidder must define the number that, in its experience, come from the client and supplier sides and state any assumptions that have been made. For the purposes of this exercise, it is appropriate to narrow the care settings to primary, community, acute and mental health settings but the range of processes should be the full scope described above.
The following paragraphs describe elements of implementation that are considered to be key.
FINAL 1.0a
Page 17 of 607
ICRS
Benefits Realisation In order to meet the stated objectives from the investment in ICRS, the selected LSPs are expected to partner with each care community in using the systems as a catalyst to help achieve their business goals and to deliver the expected benefits. Benefits fall into two broad categories - quantitative and qualitative; and, within each of these two categories, split into a further two types of benefit as follows: Quantitative Benefits In summary quantitative benefits include cash releasing benefits that avoid financial spend and other savings and also non-cash releasing benefits that provide economic benefits with a monetary value in terms of their opportunity cost o economic value to society. More detail and examples of these r benefits are presented below: Cash Releasing Benefits - measured in cash available for use anywhere in the organisation. These benefits may include the cash releasing benefits that are gained by eliminating the cost of paper request forms, or reducing/preventing unnecessary/duplicate pathology tests; and Non-Cash Releasing Benefits - these benefits can be readily counted in cash terms but local management will decide whether to release these cash savings. For instance, local managers may decide to use Health Visitors time saved on clinical documentation in ICRS to allow nurses to spend more direct time in patients homes. They may also decide to increase the pharmacists clinical advisory role as a result of order entry and clinical decision support functionality in ICRS.
Qualitative Benefits Qualitative benefits include benefits which are measurable and quantified, but not expressed in financial terms, and those that are un-measurable, but may be gauged using qualitative techniques such as patient satisfaction surveys. Measurable - these benefits will typically improve the quality of care. For example, decision support linked to direct entry by doctors should reduce the number of potential Adverse Drug Events (ADEs) in both the primary and acute sectors; and Un-Measurable - these benefits exist but cannot easily be measured. Benefits of this nature may include increased patient satisfaction, improved morale and better team working (although there are ways of estimating the quantum of these effects).
However, it is recognised that in order to realise maximum benefits from ICRS an integrated approach including people, process and technological changes is required. It is also recognised that purchasing these types of information systems is a long term investment. Clinical requirements change and evolve, technology and software will be updated and enhanced, and increasing emphasis will be placed on business process improvement and business activity monitoring tools and techniques. It is essential that any approach allows for continuous clinical quality improvements and benefits realisation.
N. Benefits Realisation Each bidder shall describe its methods used in quantifying and delivering benefits in relation to clinical information systems which are proven to work. Each bidder shall describe the method and tools it will use and illustrate how and where these have been used in practice. Each bidder shall show how this method has been used in relation to its chosen application product set and describe how methods will be integrated and enhanced over time. Each bidder shall describe how the method is used over the whole life of a service such as ICRS. Each bidder shall demonstrate that it has a full understanding of the types of benefits that will be delivered with its chosen product sets and methods. To do this, the bidder should describe the types of benefits, using the four benefit headings above, that it has identified and released in any
FINAL 1.0a
Page 18 of 607
ICRS
recent projects. The bidder must demonstrate that it understands the Authoritys business drivers and targets. To do this it should describe the extent to which its chosen product set helps meet the Improvement, Expansion and Reform (IER) and other targets. Each bidder shall describe its preferred approach for working with Clusters to help identify, quantify, and deliver a range of benefits. This should include the bidder's approach to partnering, descriptions of the potential numbers involved on each side, the high level roles and responsibilities, and an approach for joint working and success.
Innovation It is expected that the LSP will use innovative technology to deliver new solutions in areas that have not been commonly available or used in the past. These innovative solutions should address business issues such as: Patient Access one of the big issues with current healthcare delivery is that patients cannot access their own records. One of the consequences of this is they have very little ownership of their own health. New solutions must provide patient access and involvement. E -health and telemedicine technologies will be an essential part of what LSP are expected to deliver; Shifting the Balance of Power one of the key drivers that ICRS must assist in is the delivery of more healthcare locally. This means that much of the focus of ICRS needs to be around innovative solutions for the home, primary and community care delivery. Solutions must explicitly enable this shift in emphasis; Prevention Rather than Cure much of todays focus is put on curing people when they become ill, rather than helping to prevent disease or catching it sufficiently early to make a difference. Solutions must assist in redressing this balance; Patient Remote Monitoring solutions must provide the ability to monitor patients remotely for a range of conditions and in a range of settings. This information must be capable of being transferred to the patients record automatically and for appropriate alerts and analysis to be undertaken on the information captured; and Access to Knowledge traditionally, Patient Record solutions have provided the users with data and information in a limited range of formats. In future, solutions must provide knowledge and clinical support for the delivery of care. This will include, but is not limited to, clinical decision support, best practice guidelines, and knowledge repositories. This knowledge must be available wherever it is needed and must be provided on a range of devices that are designed for the environment in which they are being used (e.g., ICU, theatres, peripatetic community workers, and ambulances). Emerging Technologies solutions must provide the ability to utilise emerging technologies (e.g., voice recognition) in a cost effective manner.
O. Innovation Each bidder shall demonstrate how its solutions will utilise innovative technologies and how these will be refreshed over the lifetime of the programme. As a minimum the bidder should use the headings above, but bidders are encouraged to think more broadly. The bidder must also show how these new technologies will be incorporated and established in the Authority through process redesign and effective change management. Each bidder shall describe its approach to providing e-health and telemedicine solutions (see section 123 for guidance) and describe the range of devices that it expects users will use across the range of care settings described in this document.
Bidders are reminded that, when responding to this Part II of the ICRS OBS, the "Required Response" column in each table found in a module contains statements of required responses.
FINAL 1.0a
Page 19 of 607
ICRS
Whether or not a cell in this column has been left blank, bidders are required to state in their responses how they will meet the requirements specified on the same row for the "Requirement" column. Bidders are also required to provide each of the specific required responses, if any, shown in the "Required Response" column. Bidders are advised that all requirements are mandatory, irrespective of whether they are expressed using such terms as "should", "must", "shall" or "will".
FINAL 1.0a
Page 20 of 607
ICRS
User Environment 101 - User Tools Overview The aim of this module is to identify the core toolset which is required from each LSP to control the user environment and the operation of the component functions of Local ICRS Service and local system tailoring which will be required to support the diversity of clinical and patient needs which the LSP Services will address. It is important that such tools are provided, in order that: the diversity of clinical needs within a health community can be supported; individual users can tailor their facilities, within the standard framework for the local implementation of ICRS; and future developments may be supported more easily through the provision of tools and parameterdriven facilities which will allow local development.
Scope This module covers a number of general user requirements, providing a degree of control that users have over the behaviour of the services, and the flexibility within which users can tailor facilities to their own specific needs. Users in this context refers not just to Clinicians and associated support staff, but also to patients. The principles underlying the requirements specified are: to ensure that all Clinicians working in any care setting have access to the relevant clinical information necessary to support patients under their care; to provide Clinicians with on-line access to up-to-date guidance, evidence on effective treatment, and the information required to evaluate the effectiveness of their work; and to support professional education, development, research and the planning of services; to provide the basis for uniformity of clinical systems deployed in all care s ettings, so that comparable recording of information on activity and quality will be available to assist in the maintenance of the highest possible standards of practice; and to provide industry-standard graphical user interface functionality (e.g., history, favourites, quick logouts, back/forward buttons, etc.).
Components The following components are required: tools to enable the collection of locally-defined information; tools to support the reporting and analysis of information; parameter controls to support the behaviour of the solution to meet needs within a Cluster and the diversity of clinical practice; controls to support information governance, including but not limited to access and confidentiality; and controls to support the operation and activation of workflow as an inherent function.
Benefits and Outcomes Consistency of approach will make it easier to train users, particularly when introducing new functions. Local flexibility will allow users to tailor applications to meet their needs.
Delivery Expectations
ICRS
Minimum Level to Be Achieved by December 2004 (Phase 1) Each user to have a common log-on for all information services. Each user to be provided with basic data capture, validation and reporting services. Minimum Level to Be Achieved by December 2006 (Phase 2) Some sites will provide reporting and analysis functions. Users to be provided with facilities to enable the local generation of requirements. Target for 2010 Single log-on for all services provided by the LSP, linked to authentication, with role-based access providing a relevant set of functions for each user. Overview Requirements Requirement 101.1 Overview This module specifies the requirements for the underlying tools and tailoring capabilities of the solution set being proposed. The service shall support requirements across health and social care, whilst ensuring generic functionality is deployed across this spectrum. It shallprovide local control over the behaviour and operation of generic functions to effectively support the diversity of user requirements. It shall maintain a robust operational service which meets all performance requirements and delivers an integrated care record and an underlying data model which is consistent, accessible, structured and logical. 101.2 Benefits and Outcomes The service benefits: shall deliver the following Required Response Each bidder shall describe the basic approach to user tools, illustrating facilities provided for parameterbased controls, data capture and reporting. Each bidder shall describe any constraints which might restrict the ability of users to address their requirements.
Each bidder shall describe how users might tailor facilities to their own requirements, and the degree of flexibility provided. Each bidder shall describe how new and emerging requirements may be met through the application of the basic toolset. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to
101.3
flexibility in meeting the diversity of clinical needs across all care settings; flexibility for meeting individual user needs; and flexibility for meeting future requirements. Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP.
FINAL 1.0a
Page 22 of 607
ICRS
Requirement
Required Response deliver during Phase 1.
101.4
Authoritys Responsibilities
Each bidder must describe the responsibilities it would expect to be assumed by the Authority.
Detailed Requirements Requirement 101.5 101.5.1 Core Requirements The service shall cover all aspects of multidisciplinary and multiprofessional care, including in-patient, out-patient, unscheduled, elective, non-elective, day case, ward attendances and telephone contacts. This includes the capture of informal and formal discussions between Clinicians, whether this be in a multi-disciplinary team or over the telephone. The service shall enable the development of a detailed longitudinal picture of the patients clinical progress throughout the period of care. The service shall enable clinical data to be linked over time so that diagnoses are not duplicated in each contact and the evolution of a diagnosis can be documented. The service shall provide users with a common interface to core applications. Each bidder shall describe how the service will enable Clinicians to capture details of all contacts with patients, whatever the professional or support staff involved and whatever the medium. Required Response
101.5.2
Each bidder shall describe how this will be achieved.
101.5.3
101.5.4
Each many would order,
bidder shall describe how different applications users have to operate to admit, to to prescribe and to discharge.
101.5.5
The service shall enable the capture and linkage of changes in clinical state, such as symptoms, signs and questionnaire scores.
101.5.6
The service shall ensure that sufficient data, positively identifying the patient, is clearly visible on all screens and at all times where patient details are being entered or retrieved. The service shall allow attributable data collection by all Clinicians involved in the care of patients, including senior and junior doctors and dentists, nurses and all clinical professions, as well as secretarial and clerical
101.5.7
Each bidder shall describe how the service will provide Audit Trails, and how it will enable the individual with overall responsibility of a patient to be identified, as well as those responsible for decisions taken and
FINAL 1.0a
Page 23 of 607
ICRS
Requirement staff and, where appropriate, social workers. As part of this Audit Trail, the service shall record reference to the person who has recorded the data, the originator of the data, and where appropriate the person who has validated the data. 101.5.8 The service shall interface with other information systems to enable seamless access of data, and to minimise duplicate data entry. This might include patient administration systems, departmental systems and other clinical systems 101.5.9 The service shall conform to standards required by the Authority professional bodies as required by 770 Clinical Communications and 790 - Standards. national and by Module Module
Required Response actions performed for the data entry itself.
Relevant standards may include those for clinical language and terminology, headings, coding, datasets and technical specifications. 101.5.10 The service shall enable the collection of mandated data items to support NSFs or specific codes to support specialist areas of practice. The service shall provide a facility for temporary local codes, w hen national codes are not available for individual terms. The service shall be sufficiently flexible to allow and support organisational change and the development of new clinical processes and services, including new methods of service provision, investigation or treatment. Each bidder shall describe how this will be achieved.
101.5.11
101.5.12
Each bidder shall describe facilities for local customisation to incorporate changes in personnel or organisational structure. Each bidder shall describe facilities that would prevent the attribution of data to non-existent organisations or individuals who no longer work in the organisation.
101.5.13
The service shall enable the electronic transmission and receipt of information between primary, secondary and community health care and, where appropriate, Social Care organisations, with appropriate
Each bidder shall describe how the service will support communication between Trusts, between secondary and Primary Care, and with Social Care organisations.
FINAL 1.0a
Page 24 of 607
ICRS
Requirement safeguards for confidentiality. 101.5.14 The service shall enable Clinicians to have on-line access to the knowledge base of health care, at the point of care.
Required Response
Each bidder shall describe how Clinicians might access facilities such as the National Electronic Library for Health, the Cochrane Database of Systematic Reviews, and other literature sources in the context of the consultation or other contact with patients. Each bidder shall describe how this will be achieved.
101.5.15
The service shall enable monitoring of the training experience of junior Clinicians, and inform the appraisal of all staff with responsibility for the care of patients. The attribution of activity to all staff shall enable the monitoring of the exposure of those in training to cases, procedures and problems, and shall enable review of the outcome of care in those cases where they have been involved. The service shall provide information specifically for management purposes, including monitoring of activity and quality, as a by-product of the operational system.
101.5.16
Each bidder shall describe how the collection of clinical, demographic and administrative data in structured form might allow aggregation, so that activity, processes and outcomes can be monitored and related to changes over time to personnel and to the organisation. Each bidder shall describe facilities that will support this. any
101.5.17
The service shall support local and national research initiatives. The service shall provide on-line help for new and experienced users.
101.5.18
Each bidder shall describe help facilities that will be provided for new and experienced users. The latter should be able to access the full functionality of the system with online help. Each bidder shall describe the documentation to be provided, both in form and content.
101.5.19
The service shall be supported by full documentation. The whole documentation shall also be available in paper and electronic form. The supplier shall provide consistent application of local controls and system tailoring across the ICRS solution. The tools to support local tailoring and flexibility shall support the addition of new and emerging technologies and application system developments which are incorporated into the
101.5.20
101.5.21
FINAL 1.0a
Page 25 of 607
ICRS
Requirement solution during the life of the contract. 101.5.22 The service shall support all forms of media within the Integrated Care Record including but not limited to structured data, voice (voice annotation, voice recognition and voice records), video, digitised documents included scanned paper documents and OCR documents, digital medical images etc. The service shall remain flexible throughout the life of the contract so that it can become more refined as clinical practices and the scope of practice of professional groups evolve. Data Capture The service shall provide a rapid and userfriendly method of data input, appropriate to the context in which the service is used.
Required Response
101.5.23
101.6 101.6.1
Each bidder shall describe how the service might be provided in a wide variety of contexts, including conventional face-to-face consultations, as well as for the adhoc documentation of telephone discussions, multi-disciplinary team decisions and other issues of relevance to individual patient management. Each bidder shall describe facilities for structured, coded data capture, as well as unstructured free text. Each bidder shall describe any facilities for the incorporation of user-defined images or drawings and images collected from other sources this might include the facility to annotate such images with text, which may or may not be codeable. Each bidder shall describe the flexibility with which users can define the headings under which data are collected. Each bidder shall describe how it might be possible to mark individual data items so that they can be extracted for specific purposes. Each bidder shall describe validation facilities available. the
101.6.2
The service shall provide a mix of structured and free-text data collection, including the ability to add free-text annotations to predefined images or drawings. This shall include free-hand diagrams (for example, using a graphics tablet) and free-hand annotation of pre-defined diagrams.
101.6.3
The service shall enable clinical data to be organised under nationally- or locallydetermined headings.
101.6.4
The service shall enable selected data items to be flagged for specific purposes (e.g., clinical importance, research, etc.).
101.6.5
The service shall enable on-line validation of all structured, coded data.
FINAL 1.0a
Page 26 of 607
ICRS
Requirement 101.6.6 Users shall be able to check the accuracy of all structured data collected by review of the coded term against the user term.
Required Response Each bidder shall describe validation facilities available. the
101.6.7
The service shall allow access to such coding tables as may be nationally-determined at the time, and shall provide an automated facility to code clinical data at the point of care. The service shall be sufficiently flexible for structured data c ollection to use any coding system. The service shall enable the use of temporary codes for structured data collection where nationally-determined codes are not available.
Each bidder shall describe how the use of coding tables would be supported.
101.6.8
Each bidder shall describe how different coding systems would be supported. Each bidder shall describe how local codes may be assigned to enable new terms to be captured in structured format. Each bidder shall describe how a user can paint a new screen to collect a number of data items and how these data items will be linked to each patient's health record. Each bidder shall describe how this will be achieved.
101.6.9
101.6.10
The service shall enable users to define their own data fields for collection.
101.6.11
The service shall also enable temporary codes to be logged, so that appropriate changes are made when national codes are assigned. The service shall employ methods to simplify structured data collection, such as pick-lists, short lists and pre-coded templates. Users should be able to generate their own short lists of frequently-entered items in a variety of easily-accessible forms.
101.6.12
101.6.13
The service shall enable mandation of appropriate data fields to conform with minimum data requirements for central purposes, as identified by professional and statutory bodies. The service shall enable flexibility of the specification of data to be collected, to allow for evolution and development over time and continuing conformance with national requirements. The service shall allow all users to be appropriately identified and their access to the system to be governed by appropriate
Each bidder shall describe facilities for the mandation of data fields.
101.6.14
101.6.15
Each bidder shall describe the access facilities they propose to
FINAL 1.0a
Page 27 of 607
ICRS
Requirement safeguards, including, but not limited to skills and time windows. The service shall be potentially accessible and usable by all authorised health professionals. 101.6.16 The service shall enable the setting of date and time windows for which a user could have read and write access to any Patient Record. The service shall enable visualisation of images (e.g., x-ray, pathology and endoscopy) with the Patient Record, and incorporation of images into reports and summaries. It shall not be necessary for images to be held within a Local System if remote viewing is possible. The service shall enable the download of monitoring information (e.g., blood pressure or pulse oximetry) into the Patient Record.
Required Response provide.
101.6.17
Each bidder shall describe the facilities for users to view images held on other systems and to incorporate these into reports and summaries as necessary.
101.6.18
Each bidder shall describe how certain monitoring data, held in digital form, might be incorporated into the Patient Record if users require this. Each bidder shall describe how the use of equipment for certain procedures might be recorded, so that this can be analysed and reviewed retrospectively, including by providing the ability to link equipment to individual patients and to operators. Each bidder shall describe how this will be achieved.
101.6.19
The service shall enable capture of data on equipment use.
101.6.20
The service shall enable capture of data on complications, both clinical and technical, during and after investigations and procedures. The service shall allow clinical data captured after an investigation or procedure to be linked to that action, if appropriate. The service shall enable capture of multi-item measures (such as quality of life, activities of daily living, and severity measures) and automatic score calculation. The service shall allow local configuration of such measures as required.
101.6.21
101.6.22
Each bidder shall describe how the service will allow local incorporation of multi-item measures, with automatic coding of the constituent items and automatic calculation of scores. Each bidder shall describe how it might be possible to link such recordings over time, so that outcomes can be monitored.
FINAL 1.0a
Page 28 of 607
ICRS
Requirement 101.6.23 The service shall enable capture of technical data in appropriate clinical contexts, such as radiotherapy, endoscopic and physiological monitoring procedures, and other interventions.
Required Response Each bidder shall describe how the service can enable linkage to systems which record in detail the technical component of diagnostic and therapeutic procedures, so that this data can be accessed by users.
101.7 101.7.1
Workflow The service shall incorporate workflow as an inherent component of the system. Workflow will involve the identification and allocation of tasks to specific individuals or groups of individuals, management and tracking of tasks to completion, and controls, including triggering of alerts where tasks have not been completed. Tasks will be allocated as a by-product of key actions, including but not limited to order entry (e.g., task assignment to phlebotomist to take blood); results reporting (e.g., task for medical staff to acknowledge receipt of a result); and care planning and ICPs (e.g., task assigned to nursing staff to change dressing). Each bidder shall describe how workflow has been incorporated within the solution. Each bidder shall describe how workflow is controlled and tailored to meet the diversity of needs across all healthcare settings.
101.8 101.8.1
Process Support The service shall enable direct communication between professionals across all healthcare settings. Each bidder shall describe how the service will support electronic communication between professionals - without breaching patient confidentiality. Each bidder shall describe facilities for external communication, including the ability to communicate with suppliers of goods and services so that, as resources are depleted, reordering is facilitated.
101.8.2
The service shall enable direct communication with suppliers of goods and services.
101.9 101.9.1
Data Retrieval The service shall be secure and confidential, and only accessible on a need-to-know basis to authorised users. Each bidder shall describe local customisation facilities, including the ability to set up individual users with access as appropriate to need. Each bidder shall describe how read and write access will be monitored within the system. Each bidder shall describe how users may retrieve data appropriate
101.9.2
The service shall produce an Audit Trail of user access to data.
101.9.3
The service shall provide efficient and speedy
FINAL 1.0a
Page 29 of 607
ICRS
Requirement retrieval of data by appropriate personnel.
Required Response to their need, both on individual patients and in aggregate form. Each bidder shall describe how individual patient summaries might be customisable at a local level. Describe how this will be achieved.
101.9.4
The service shall produce individual patient summaries and reports, the format of which can be defined by users. The service shall enable summaries and reports to be transmitted to other systems (including Primary Care) as an appropriate mix of free-text and coded data. Electronic linkage to other systems across all care settings must facilitate the transmission of free-text and coded data.
101.9.5
101.9.6
The service shall enable data to be incorporated seamlessly into office automation products, such as word processing. The service shall provide the ability to produce ad hoc reports without the need for specialist technical ability.
Each bidder shall describe facilities that it will provide.
the
101.9.7
Each bidder shall describe how users could set up their own analysis of the data held on the system, without the need for recourse to specialist help. Each bidder shall describe facilities for the automatic generation of reports. Each bidder shall describe the facilities for producing a suite of reports for users, and the flexibility for changing these as requirements develop.
101.9.8
The service shall enable users to schedule reports, where appropriate.
101.9.9
The service shall provide an ability to customise data reports to support differing information needs by professionals to support the specific information needs of different types of Clinicians and each patient's health record. The service shall enable the analysis of aggregate data for monitoring of quality (including outcomes), planning new services, supporting research activity, and the monitoring of training. This will require the ability to analyse by clinical headings and coded terms, patient demographics, staff, organisation, Episode, location and referral source. The service shall enable the production of longitudinal views of the patients progress, including changes in symptoms and diagnosis and their severity, and the progress of
101.9.10
Each bidder shall describe the facilities for comprehensive analysis and presentation so that interrogation is possible by suitably trained local staff.
101.9.11
Describe how this will be achieved.
FINAL 1.0a
Page 30 of 607
ICRS
Requirement laboratory tests over time. Outputs must include the ability to produce a sequential picture of a patients progress, including all contacts with different professionals and linkage of diagnoses, symptoms, multi-item scores and test results over time. 101.9.12 The service shall provide the facility for graphical representation of data. The service shall enable tracking of patient location across care settings and by Clinicians responsible for their care.
Required Response
Each bidder shall describe the facilities for graphical presentation. Each bidder shall describe how users can identify the location of individual patients. Each bidder shall describe how aggregate reports can be generated, identifying the healthcare professional who is responsible for management, diagnoses, procedures and other clinical data.
101.9.13
101.9.14
The service shall enable monitoring of waiting lists, booking lists and waiting times.
Each bidder shall describe how users can monitor the number of patients on a waiting list for consultation or procedure and the times that patients are waiting. Each bidder shall describe how users can access numerical and free-text investigation results. Each bidder shall describe how data integrity is maintained in the event of system failure.
101.9.15
The service shall enable access to results of investigations and tests, in both structured and free-text form. The service shall allow the export of raw data in the event of system failure.
101.9.16
101.10 101.10.1
Remote Access to Information The service shall enable access to information about individual patients held on the Spine or on other ICRS implementations outside the care community. Each bidder shall describe the facilities for users to interrogate an individual patients health record with appropriate confidentiality safeguards. Each bidder shall describe how Clinicians can access the knowledge base of health care at the point of contact with patients.
101.10.2
The service shall enable remote access to research papers, reviews, guidelines and protocols.
101.11 101.11.1
Clinical Stakeholder Engagement The supplier shall establish a mechanism to engage with the robust clinical
FINAL 1.0a
Page 31 of 607
ICRS
Requirement communities within their Cluster by geography and speciality to ensure that the solution meets their needs throughout the life of the contract. 101.12 101.12.1 Set-up and Management The functionality to support the set up and management of local parameters, screen layout, definition of local data items, rules, reference files and access controls and other tools which control the user environment shall be logical and intuitive and shall enable additions and changes to be audited. The service shall provide appropriate help facilities in setting up and managing the local tailoring of the solution. User tools shall enable local preferences to be mapped to national data standards
Required Response
101.12.2
101.12.3
Each bidder shall describe how the overall integrity of the ICRS solution is maintained within the context of enabling local flexibility.
FINAL 1.0a
Page 32 of 607
ICRS
Generic Functions 102 - Patient Index Overview This module describes the requirements of the local patient indexes. They must link closely with Module 210 - Personal Demographic Services in Part I of this OBS and Module 440 - Interfaces To / Use of Existing Health Service Infrastructure in Part III of this OBS. Benefits and Outcomes Current Situation Typically, each Trust and GP practice holds its own patient index. Such indexes are usually not linked; hence, there is a requirement to synchronise patient information across the care community. In each former health authority, there is a NHAIS which holds records for those patients registered locally with GPs. Local GP systems provide regular updates to their local NHAIS. National tracing services are provided through the NHS Strategic Tracing Service. A service providing NHS Numbers for Babies was implemented in late 2002. Desired Benefits and Outcomes The service shall provide a method to ensure that all systems and services for which the LSP is responsible use the national PDS as their unique source of patient demographic information. Local Systems will need to hold temporary supplementary information. The main benefits sought from the patient index service are as follows: use of a common unique patient identifier (NHS Number) enabling linkage with other systems; e.g., Social Services or the Spine; reconciliation of the patient identification record across disparate systems and care settings; elimination of duplicate entry of data; data consistency, timeliness and integrity of patient identification data across systems; and provision of the most up-to-date information to all component ICRS functions/systems.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) It is expected that most sites will already have personal demographics modules present at this stage. However, for some sites it will be necessary to replace existing systems with the LSP's chosen product set. Minimum Level to Be Achieved by December 2006 (Phase 2) 50% integration with the PDS, as defined in Part I of the OBS. Target for 2010 Full integration with the PDS, as defined in Part I of the OBS. Overview Requirements
FINAL 1.0a
Page 33 of 607
ICRS
Requirement 102.1 Overview This module specifies the requirement for the underpinning index of patients.
Required Response Each bidder shall describe its approach to delivering the requirements for shared patient indexes. Each bidder shall describe how it intends to work with the national PDS (See Module 211). With reference to Module 211, relating to a national PDS, bidders are asked to respond to this section by defining how they would integrate the systems they have responsibility for under this Part II of the OBS with the PDS.
102.2
Benefits and Outcomes The implementation of the shared index will be a critical first step to the implementation of care records.
Each bidder shall describe the benefits it could expect to see from patient index functions, and describe how it would provide quick win benefits. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it w ould expect to be assumed by the Authority.
102.3
Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP.
102.4
Detailed Requirements 102.5 102.5.1 Interfaces to External Services The service shall provide a facility to support online patient tracing using the national PDS (see Module 440 for more details). The service shall support on-line tracing using the NHS Strategic Tracing Service. The service shall receive update from the national NHS Number for Babies service. Each bidder shall describe how it would support interfaces with other local and national services. Each bidder shall describe how it will implement on-line tracing. Each bidder shall describe how it will implement links to NHS Numbers for Babies. Each bidder shall describe how it would support the management of multiple indexes within a health
102.5.2
102.5.3
102.5.4
The service shall provide a method to ensure that all systems and services for which the LSP is responsible use the national PDS as
FINAL 1.0a
Page 34 of 607
ICRS
Requirement their unique source of patient demographic information and the NHS Number as a common unique patient identifier. 102.5.5 The service shall provide the access point to the national patient demographic service (211) as the master patient index for patients with an NHS number. Registration The national PDS shall be used by staff as the core registration facility.
Required Response community.
102.6 102.6.1
Each bidder shall describe how users will be presented with registration facilities.
102.6.2
The solution shall allow previously-registered patient details to be utilised by staff without entering a new registration. The service shall prevent some fields (e.g., the NHS Number) from being updated on-line. The service shall prompt user with "Are you sure?" or similar questions before accepting updates to patients' demographic details. Each bidder shall describe facilities for selective updates to fields. Each bidder shall describe facilities that restrict updates of certain fields to identified users. Each bidder shall describe the validation criteria that will be provided. Each bidder shall describe how rules can be created and maintained.
102.6. 3
102.6.4
The service shall include facilities that minimise the creation of duplicate or inaccurate patient registrations. Rule-type intelligence shall be incorporated, allowing certain mandatory fields to be ignored in certain circumstances (e.g., in A&E, when certain details are unlikely to be known at that time). Full reporting on any missing mandatory fields shall also be possible. The service shall provide a facility to enable patient treatments/interventions to be captured on the system for those whose identity and other details are not known at the time of registration. The service shall allow a patient (e.g., a new baby) to be registered with minimal details.
102.6.5
102.6.6
102.6.7
Each bidder shall describe how this will be achieved, and how it will link with the NHS Number for Babies service.
102.6.8
The service shall ensure that the patient registration and associated events/interventions are as near to real-time as possible and are consistent.
FINAL 1.0a
Page 35 of 607
ICRS
Requirement 102.6.9 The system shall produce reports of potential duplications and shall provide a facility for the user to merge duplicate records, where appropriate. This facility should allow the user to indicate those data items to be transferred. Temporary Registration The service shall provide facilities for quick registration and allocation of a temporary ID for example in the event of a major incident.
Required Response
102.7 102.7. 1
Each bidder shall describe facilities for fast registration. Each bidder shall describe facilities for ensuring that such registrations are tidied-up" later.
102.7.2
The service shall enable the addition of userdefined identifying details to the Patient Record to allow identification at a later stage (e.g., in the case of an unconscious patient or a major incident).
Each bidder shall describe how the service would support a registration made in A&E with minimal or incorrect data, and how the missing or incorrect data may be highlighted and duplicates exposed. Each bidder shall describe the fields to be completed for such records.
102.7.3
The service shall support: fast-track recording for emergency cases; patients who - for whatever reason - are unable to provide information about themselves; temporary records, where patients move into the health community for limited time periods and require access to Primary Care services provided by GPs; those who are not registered with a GP; and special records for a limited range of services; e.g., contraception services. The service shall support the recording of overseas visitors.
102.7.4
Each bidder shall describe the facilities for recording overseas visitors. Each bidder shall describe the facilities to meet this requirement, particularly where a patient may have multiple Episodes.
102.7.5
The service shall support the recording of private patients.
102.7.6
The service shall trigger an alert requesting the completion of any incomplete fields (e.g. NHS No.) whenever a Patient Record linked to a temporary registration is accessed. Patient Index Requirements
102.8
FINAL 1.0a
Page 36 of 607
ICRS
Requirement 102.8.1 The service shall store temporary addresses with users having the option to choose a destination for letters. These temporary addresses shall include residential special schools, home leave from MH in-patient care, prisons, bail hostels etc. 102.8.2 The service shall enable the recording of date parameters against all addresses (temporary addresses or those held in the PDS) together with a status indicator itemising source, validity and priority of individual addresses (e.g., to support the recording of future dates where addresses may be recorded in advance). The service shall enable the specification of where correspondence is to be sent, as well as where any copies shall be sent (e.g., if a copy needs to go to an individual stored in the contact details, such as a relative or carer). The service shall contain intelligence to control which considered current. rule-based address is
Required Response Each bidder shall describe how temporary addresses will be managed.
Each bidder shall describe any date parameters that might be used, and how they operate.
102.8.3
Each bidder shall describe facilities for specifying correspondence destinations.
102.8.4
Each bidder shall describe how rules-based intelligence might be applied. Each bidder shall describe how such facilities would relate to the national PDS.
102.8.5
The service shall support the ability to record first language choice for patients, including sign language, and provide translation services for letters and other communications. The service shall support the automatic transfer of patients between GPs when one retires, leaves, etc. This shall be rule-based, so that it allows only patients between certain date-parameters to be moved. This shall be synchronized with current national systems and services (e.g. NHAIS). The service shall transfer information to the PDS so that patients' records shall be closed. This shall be achievable on both an ad-hoc and systematic basis, for the following reasons: death of the patient; change of residence of the patient to another care community; and patient discharged from all services and
Each bidder shall describe how this may be recorded.
102.8.6
Each bidder shall describe how such transfer might be effected, and the parameters within which lists might be generated and acted upon.
102.8.7
Each bidder shall describe the facilities for the closure of Patient Records and the circumstances in which this might occur.
FINAL 1.0a
Page 37 of 607
ICRS
Requirement not registered with a GP within the care community and not resident within the care community. The service shall record the date of closure and the user authorising/undertaking the closure. Date of death entry shall facilitate complete Episode validation to close active or forthcoming events.
Required Response
102.8.8
102.8.9
Each bidder shall describe how this might be achieved, allowing that certain activities might still be appropriate after death. Each bidder shall describe how this might be achieved, allowing that certain activities might still be appropriate after death. Each bidder shall describe how this facility might be achieved, and any safeguards to its use.
102.8.10
Entry of date of death shall prevent most further actions being undertaken, such as, but not limited to, scheduling of Episodes, resources, investigations or correspondence. Dates of death shall also be capable of being removed and the closed Episodes re-created.
102.8.11
102.8.12
There shall also be the ability to batch upload date of death data from files and for the appropriate validation to then be carried out. This process shall be supported by a maintainable, rule-based process. There shall be the ability to identify patients with special needs or nursing considerations; e.g., infectious cases or disabilities. The patient index service at local level shall enable patients without NHS numbers to be registered. Suppliers are asked to describe how these records will be managed on the local index and how they will be maintained locally.
102.8.13
102.8.14
102.8.15
The service shall support identification of patients who are unable to provide full identification details e.g. unconscious patients.
Suppliers are asked to describe how these records will be managed on the local index and how they will be reconciled with the PDS when details become available. Suppliers are asked to define what facilities are available to enable patients to be registered without full key information and to describe how these records are managed to ensure users are prompted to record missing information as soon as this becomes available.
102.8.16
Where communication with patients is indicated the service shall enable use of
FINAL 1.0a
Page 38 of 607
ICRS
Requirement methods to communicate with patients with special needs shall include those with learning disabilities, e.g. Aspergers Syndrome and Autism. 102.8.17 The Service shall be able to hold details of a childs care arrangements such as fostering and placement address. The service shall be able to re-assign patients and their planned activities from one practitioner to another. Provide Facility to Search Index The service shall support searching on the following criteria, both current and historic: patient ID (local numbers and NHS Number); surname; former names; maiden name; forenames; middle names; part names; date of birth (with ranges); date of death (with ranges); gender; postcode or part postcode; address or part address; unique location reference; aliases and "prefers to be known as"; temporary addresses or part temporary addresses; and name of GP.
Required Response
102.8.18
102.9 102.9.1
Each bidder shall describe the searching facilities, and the fields which may be searched. Each bidder shall describe how searching will be achieved in relation to the national PDS.
FINAL 1.0a
Page 39 of 607
ICRS
Requirement 102.9.2 The service shall display sufficient detail of match results to enable easy identification of the correct patient. The same level of f exible searching shall be l possible remotely, as well as internally. The service shall support phonetic searching on names. The service shall support the linkage of disparate individuals into family groups (see Section 166 Children's NSF). The service shall integrate with and automatically use postcode validation software to derive addresses or assign a postcode. The services shall use national standard GP reference numbers. The system shall be capable of linking and searching for the records of siblings and biological mother except in the case of adopted children. The service shall have the capability to uniquely reference each location / address. The National Land and Property Gazetteer is an example of such a referencing mechanism. Ability to Provide Reports and Other Output The service shall enable the production of statutory and user-defined reports on available information in paper and electronic format. The service shall provide a facility to print user-defined labels, front sheets, etc. (NHS Number and status to be included on all labels, front sheets and correspondence). Full bar-coding functionality shall be supported, including the provision of barcoded wristbands and production of bar-codes on patient letters, appointment cards, and all labels and prints. User-definable exception reporting shall be possible, on-screen, in print and electronically.
Required Response
102.9.3
102.9.4
Each bidder shall describe facilities it will provide.
the
102.9.5
102.9.6
102.9.7
102.9.8
102.9.9
102.10
102.10.1
102.10.2
102.10.3
102.10.4
FINAL 1.0a
Page 40 of 607
ICRS
Requirement Missing data items shall be identified with appropriate warning Messages when records are viewed or updated. 102.10.5 The service shall support production of patient identity tags to enable patients to be tracked through different departments and locations easily. This will ensure patient ID verification processes, e.g. drug administration can be facilitated. Communication Referrers with Patients and
Required Response
Suppliers are asked to indicate what method(s) of patient ID tagging can be supported by the solution, e.g. bar coded wristbands, radio frequency ID tags etc.
102.11
102.11.1
The service shall enable special needs for patients to be reflected in the style of the communications with them (examples of patients with special needs might include those with visual impairment or whose first language is not English). The service shall enable the copying of letters to patients. This initiative (which was a commitment in the NHS Plan) will be implemented across the NHS.
Each bidder shall describe how it would support communications with patients and referrers.
102.11.2
Each bidder shall describe how facilities for the copying of letters to patients might be implemented.
FINAL 1.0a
Page 41 of 607
ICRS
103 - Prevention, screening and surveillance Overview The purpose of this module is to support national and local promotion, prevention, screening and surveillance programmes. These include programmes which are designed to: reduce the risk of patients developing a problem or condition and requiring care; identify or detect the incidence of problems and conditions at an early stage to improve the subsequent outcomes of care; and monitor the status of patients with longstanding problems or conditions to ensure that optimal care outcomes are achieved.
ICRS must support these proactive services in all care settings, including: targeted health promotion, such as dietary advice; prevention, such as vaccination and immunisation; screening, such as screening for various types of cancer; surveillance, such as childhood development checks; and on-going management of chronic conditions, such as diabetes.
The provision of these services will involve referral of patients to, for example, other service providers and to book appointments for further investigations, or to order the laboratory analysis of tests. Scope The LSP Services must support all existing prevention and screening programmes. Where feasible, this support should be provided through generic modules or components, which may be tailored to meet the requirements of a specific programme. The LSP Services must be sufficiently flexible to support new prevention or screening programmes and changes to existing programmes, which may be a result of the opportunities afforded by developments in medical technology or reflect research evidence. Prevention and screening programmes may be based on national standards and criteria for selecting the persons within target groups to receive the service and for determining the frequency of screening; or may, in some instances, involve local standards and criteria. Existing programmes include but are not limited to: prevention programmes: childhood vaccination and immunisation; flu vaccination; meningitis vaccination; screening programmes: breast, cervical and bowel cancers; persons at risk of or with diabetes, including regular retinopathy screening; persons at risk of or with CHD;
FINAL 1.0a
Page 42 of 607
ICRS
antenatal and neonatal screening for a range of conditions; and surveillance programmes: preventative services for children during school age.
The scope of a number of these programmes is summarised below. Childhood Vaccination and Immunisation The childhood vaccination programme begins at birth with selective use of BCG and Hepatitis B vaccines; then, at two months of age, the first of three primary immunisations against diphtheria, pertussis (whooping cough), tetanus, polio, haemophilus influenzae meningitis (Hib) and meningitis C is administered. At 12 months of age, babies receive the first of two immunisations against measles, mumps and rubella (MMR). Boosters are given before school entry and at age 15, and school children are also immunised against tuberculosis at age 13 (the BCG vaccination). Immunisations are commonly given in GP practices. In most areas, each pre-school child will have a Personal Child Health Record (PCHR - for the purposes of this module). Depending on local policy, this will be given to mothers antenatally, or in the neonatal period. It is intended that the parent should produce it at each contact with a health professional and that it should become the primary record of the child's growth and development. Immunisations and other health events are recorded by Clinicians and by parents. Most versions of the PCHR incorporate pages for recording the results of the immunisations. Results of neonatal screening shall be recorded in PCHR, as well as the NHS Number, contact details of the Health Visitor, etc. The PCHR is usually arranged chronologically, with important health promotion messages inserted at the appropriate times. In areas, there are plans to extend the use of the PCHR into the child's school years. There is a national working group examining the potential for a standard format PCHR for England. Scotland already has one. A series of immunisations against Hepatitis B is offered to babies born to mothers who are defined as being at risk of having been in contact with the disease or as being a carrier. Each child on the programme requires blood tests at certain intervals from the date of the previous Hepatitis B immunisation. These blood tests are designed to identify whether the child has become immune to the disease. If the child is found not to have become immune, another immunisation is given and a repeat test is scheduled. Currently-recommended programmes for immunisation in the United Kingdom will be found in the i document, "Immunisation Against Infectious Disease," published jointly by the Department of Health, Welsh Office, Scottish Office Department of Health and DHSS (Northern Ireland). This publication is updated regularly. Screening of Those at Risk of or with Diabetes and CHD The NSFs for CHD and diabetes include standards for the development of prevention services, which target those at risk of developing CHD and/or diabetes within local populations, providing opportunities for regular screening and assessment of risk and support and care to enable at-risk people to modify these risks. These will have to include proactive supported programs that use one to one consultation, group support and website (myhealthspace) for sustained lifestyle change. These will be supported programs including diet, exercise and stress management, and will depend on ambulatory monitoring systems similar to those used in patients with established disease under surveillance. The NSFs also include standards for the screening, assessment and review of patients who have CHD and diabetes. In particular, the NSF for diabetes contains targets for the systematic retinopathy screening of persons with diabetes.
FINAL 1.0a
Page 43 of 607
ICRS
Screening for Cancers There are different screening processes for specific cancers. In the screening process for cervical abnormalities and prostate cancers, initial testing will result in the referral of patients to other service providers for further investigations and tests if a person within the target group is suspected of having prostate cancer. It requires support for the laboratory analysis of specimens taken by care professionals in the primary and community care settings. The screening process for breast and bowel cancers covers all of the stages involved in the investigation and diagnosis of cancers, including the selection and invitation of persons to be screened, the investigations undertaken, the assessment of the results of these investigations and any subsequent investigations required, diagnosis and development of a treatment plan. The latter stages will only apply to those persons for whom screening has detected a suspected cancer. Initial screening tests may take place in a number of settings: within general practices; within specialist screening centres or units (e.g., mammography units); and in the home (e.g., for faecal occult blood (FOB) tests for bowel cancer).
Figure 1, below, illustrates the steps involved in screening for cancers. Figure 1
All programmes
Identify persons to be screened
Invite individuals to be screened
Undertake initial screening investigations
Cervical
Book GP Appointment
Communicate and act on results
Breast
Receive referral
Bowel
Undertake further testing and staging
Undertake assessment and investigation
Develop treatment plan
Not all of the steps illustrated in Figure 1 apply in the case of screening for certain cancers: screening for prostate cancer is a risk management programme, rather than a screening programme, and does not involve the issue of invitations to a population-based target group; and tests for bowel cancers are undertaken by patients at home, and the analysis and investigation of these tests involves the receipt at a laboratory of a kit returned by post.
FINAL 1.0a
Page 44 of 607
ICRS
Within some cancer collaboratives, following initial investigation, women are referred directly to clinics as part of the screening for cancers of the cervix; rather than asking them to book an appointment with their GP. Screening for Inherited Cancers This is not a population screening programme, as testing is limited to those known to be at risk because they have a particular gene. Antenatal and Neonatal Screening All babies are tested for phenylketonuria (PKU test) and for congenital hypothyroidism (TSH test). Blood is taken from the baby by the midwife, by means of a heel-prick, and is sent to a regional screening laboratory. Abnormal PKU or TSH test results indicate that a child's intellectual development and functioning will be impaired unless treatment is instituted promptly. The results of these tests are sent to child health departments from the laboratory. Any abnormalities detected are notified directly to a named paediatrician in each area, but it is the responsibility of child health departments to ensure that no test has been missed. Weekly reports are run to identify babies for whom no result has been received. If a child has not had the test in the neonatal period (i.e., the first 28 days after birth), the community midwife is notified and she will visit to take a blood sample for testing. A linked antenatal and neonatal screening programme for cystic fibrosis and thalassaemia and other haemoglobinopathies were announced in the NHS Plan, to be introduced by 2004, and LSPs must support the introduction of this programme. It is also being recommended that universal screening of all neonates for sickle cell disorders should be implemented. A national working group is considering details of the implementation. A programme centre has been set up under the National Screening Committee to undertake these functions. It shall introduce further screening programmes for other inborn errors of metabolism. Please refer to <http://www.nsc.nhs.uk/ch_screen/child_main.htm>. It is intended to implement a hearing screen for all newborn babies in England. Twenty areas have been selected to start the process and, following a positive evaluation, the programme will be introduced gradually across the country. It is anticipated that all SHAs in England will be participating by 2006. The national evidence-based protocol is to screen all babies in the hospital prior to discharge. The aim of the screen is to identify children with moderate, severe and profound bilateral permanent hearing impairment. The recommended procedure is for all babies to have an Automated Otoacoustic Emissions (AOAE) test. Those who have a normal response are regarded as passing the screen, although it is possible for an infant to have a "normal" emission with a limited frequency range of normal hearing. Those who fail the initial screen undergo a second AOAE screening. All babies who fail the second EOAE screen should then undergo an Automated Auditory Brainstem Response (AABR) test. School Health Primary Care Trusts have responsibility for ensuring that preventative services are available to children attending state schools within their boundaries. Each school will have a named school health nurse, who provides support to staff and pupils in school. The services provided include screening of growth, h earing and vision, health interviews and immunisations. Older children are offered drop-in counselling and advice sessions in school. As with services for younger children, the emphasis has
FINAL 1.0a
Page 45 of 607
ICRS
changed in the last decade, so that routine screening of all children has been reduced and children with special needs (both educational and social) receive a larger share of the available resources. Components There are a number of high-level generic processes involved in the provision of screening and surveillance service shall support. These include: identifying the target group within a population to be covered by the programme; communicating with individual persons within this target group; booking appointments for prevention, screening or surveillance activities; requesting and scheduling of resources to enable these appointments; providing the prevention, screening or surveillance activities; ordering the analysis of tests or specimens taken during screening; interpreting the results of tests and investigations; recording details of the outcomes within the patient's record; communicating the results of the activities; and recall and subsequent care for persons with abnormal screening results.
The detailed content of these processes will differ according to the programme. The generic support that LSPs must provide for booking, requesting services, scheduling resources, ordering tests, interpreting and reporting results, and recording outcomes is detailed in other modules. This module illustrates the application of this generic support for prevention, screening and surveillance programmes. In providing its required responses for this module, each bidder shall indicate how it intends to apply generic functionality to the requirements of these programmes. LSPs must also enable the monitoring of uptake of specific programmes, both by individuals and for classes of persons. For the latter, LSPs must support the abstraction of data at the personal level, as well as its aggregation and the construction of a range of indicators. Data abstraction and reporting is, similarly, a generic requirement, and bidders must indicate how common tools will be used to meet the requirements associated with these programmes. LSPs must also support the quality assurance of screening processes. At present, for cancer screening these processes are supported by identifying patients within cancer registries whose cancer was detected through processes other than screening, and abstracting data relating to these individuals. Details of screening Episodes for these individuals are maintained within NHAIS. Benefits and Outcomes Current Situation Typically, current prevention and screening activities are supported by a range of different systems, within separate organisations, without integration. Desi red Benefits and Outcomes The service requirements specified in this module should enable: the comprehensive identification of persons at risk of developing particular problems, to enable implementation of systematic prevention programmes, which will lead to a reduction in the incidence of these problems or conditions; and improvements in the coverage of screening programmes in order to detect the incidence of problems and conditions at an early stage, which will lead to improvements in the subsequent outcomes of care.
FINAL 1.0a
Page 46 of 607
ICRS
This should enable the targets for reductions in the incidence of conditions, and for reductions in the mortality from diseases such as cancer and CHD, to be achieved. To: Patient Efficient call and recall for prevention and screening programmes, with guaranteed appointments and, in some instances, choice of location. Reduced incidence of disease and early detection to ensure better outcomes. Support programs of lifestyle change in those people identified at increased risk of developing hypertension, CHD, diabetes. Improved access to information on an individual's screening, vaccination and immunisation status. Clinician and Manager Reductions in the time taken to capture and record risk factors and the outcomes of screening, and improvements in the consistency of information for selecting persons and targeting inputs. Workflow support to reduce the time spent in call and recall processes, and in identifying persons who have not attended for screening. Improved access to information to monitor the take up of screening and prevention programmes, and the quality and effectiveness of these programmes.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) LSP Services solutions should be capable of supporting existing prevention and screening processes and supporting the achievement of targets for the introduction of new programmes as defined in current NSFs. This may be through the integration of contemporary systems with new LSP generic components. Minimum Level to Be Achieved by December 2006 (Phase 2) All new programmes to be supported through LSP components. Target for 2010 All prevention, screening and surveillance services should be capable of being supported through LSP components. Overview Requirements Requirement 103.1 Overview Required Response Each bidder shall describe its approach to supporting the requirements for screening, including the elements that it will supply and the components that it expects to be in place already. Each bidder shall describe how it would deliver the benefits and outcomes from this module.
103.2
Benefits and Outcomes The service shall deliver the following
FINAL 1.0a
Page 47 of 607
ICRS
Requirement benefits: the comprehensive identification of persons at risk of developing particular problems to enable implementation of systematic prevention programmes, which will lead to a reduction in the incidence of these problems or a reduction in the morbidity or mortality caused by them; and improvements in the coverage, effectiveness and efficiency of screening programmes to detect problems and conditions at an early stage, which will lead to improvements in the subsequent outcomes of care.
Required Response
103.3
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 2. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
103.4
Detailed Requirements for All Prevention and Screening Programmes Requirement 103.5 103.6 103.6.1 Identifying Persons Eligible for Prevention Programmes or Screening Core Requirements The service shall support the systematic recording of major risk factors associated with the incidence of certain diseases or conditions within a patients record. The service shall provide decision support for care professionals to ensure these are systematically identified. (See Modules 106 Clinical Noting and 112 - Decision Support). The service shall support prevention at the point of care by: highlighting lifestyle and other risk factors which are amenable to preventive measures at the point of care; Each bidder shall describe the support to be provided for capturing risk factors. Describe how generic noting and decision support may be applied. Required Response
103.6.2
Suppliers are asked to identify what features are available within the solution which will assist health and social care staff in targeting prevention and health promotion at
FINAL 1.0a
Page 48 of 607
ICRS
Requirement
Required Response the point of care.
interfacing with risk calculation modules e.g. Framingham heart disease calculator; ensure that appropriate (defined in each Cluster) Clinicians are aware of the status of at risk children at the point of care; and ensure that records in some care settings e.g. A&E, operating theatres, include setting specific warnings e.g. HIV and hepatitis.
103.6.3
The service shall support health and social care professionals in identifying lifestyle and other risk factors to the patient which are amenable to preventive measures at the point of care using rules based intelligence within ICRS. This should also include i entification d of potential risks to the patient based on the risk factors and medical history which are contained within the record. The service shall support health and social care professionals in the follow-up of patients who have abnormal results identified as part of a specific screening programme, alerting healthcare professionals on receipt of an abnormal result and follow-up processes to ensure the patient is notified, scheduled for appointment and attends the appointment. The service shall support prevention surveillance and screening at an organisation/practice, community and population level by enabling: automatic generation of primary and secondary disease and prevention registers, for diseases such as tuberculosis, diabetes, coronary heart disease and specific cancers; automatic notification of registers of an event e.g. patients who suffer a heart attack are automatically placed on the secondary prevention register in their community and the relevant Clinician notified; and automatic audit of uptake of prevention programmes especially those subject to NSF targets. Bidders are a sked to describe how use of myhealthspace and e -health components can be applied to provide supported risk prevention lifestyle changes.
103.6.4
103.6.5
Bidders are a sked to describe how use of myhealthspace and e -health components can be applied to provide supported risk prevention lifestyle changes.
FINAL 1.0a
Page 49 of 607
ICRS
Requirement 103.6.6 The service shall support screening activities within any care setting (eg mammograms in the acute sector or cervical smears in the community care sector). The service shall support screening by enabling: improved
Required Response
103.6.7
a personal cradle to grave screening register; automatic generation of screening lists at a GP practice level; automatic notification at the point of care if screening is overdue; links with pathology and other hospital systems to ensure a closed audit loop for abnormal results; screening lists should include a communication log so that a record is generated each time a patient is informed that screening is due; records should show if patients have made an informed decision not to take part in a screening programme. in some specific situations, hospital Clinicians should be aware of a patients screening status e.g. a Gynae OPD to enable opportunistic screening primary care record should be updated automatically; and child surveillance screening should include school medicals and some vaccinations outside the community healthcare setting. The results of medicals should be included within the ICRS.
Bidders are asked to describe how use of myhealthspace and supported lifestyle programs using e-health components are applied to support these requirements.
103.6.8
The service shall have the ability to support ad hoc immunisation programmes as well as additional vaccinations being added to the primary immunisation programme temporarily or permanently. Where screening targets are linked to performance targets and remuneration, the
103.6.9
FINAL 1.0a
Page 50 of 607
ICRS
Requirement service shall automatically de-personalise and collate registers and present information in the appropriate format to practice, community and national departments. 103.6.10 In PCTs, screening is directly linked to practice remuneration. The services shall provide reporting information which will directly interface to remuneration systems. The service shall be flexible and scaleable. The service shall support better surveillance by providing information for secondary purposes which will be used to provide, for example:
Required Response
103.6.11 103.6.12
disease disease;
maps
showing
clusters
of
collation of data to track the spread of an outbreak of disease or a chemical / biological attack; and notification of surveillance information
to NHS Direct, GPs and A&E in near real time.

103.6.13 The services shall enable the recording of locally defined result information following a screening attendance/event. This information shall form part of the patients "cradle to grave" screening record A comprehensive screening record will require input from the schools health service. Newborn Screening 103.6.15 Newborn screening involves disparate agencies including obstetrics, community midwifery, child health systems, health visitors, GPs and hospital specialists. The service shall support through generic functionality effective communication between these groups, including shared access to information, messaging and interfacing of data between systems. Population Mapping Surveillance and Morbidity
103.6.14
FINAL 1.0a
Page 51 of 607
ICRS
Requirement 103.6.16 The service shall automatically include all patients with specific diseases or risk factors within the respective disease register. Each time a patient attends for care for a disease for which there is a register, the service shall cross check with the relevant register to ensure that the patient is already included. If it is a first presentation for that patient, the service shall generate an alert. Children in School The service shall enable care professionals to access a directory of schools within care communities, including a unique school code, (local education authority number and school number), school name, school category (e.g., infant, senior, special, etc.), address and postcode. This shall include schools which are outside the care community but are attended by pupils who are resident within the care community. This may be a specific instance of generic Directory Services. The service shall enable users to identify which care professionals provide services at each school. The service shall maintain, for each child, the school details, including the date when the child entered, changed or left school. The service shall support changes of details for both individual children and specified groups of children (for example, when changing from primary to secondary school). Selection of Individuals Within Target Groups The service shall enable automatic selection of persons within a target group of a population who are eligible for prevention and/or screening programmes during a particular time period. The service shall enable users to define criteria/rules for selection of individuals to be included in the programme (e.g., age, sex, elapsed time since previous screening or prevention, medical history, family history, results of previous tests and life-style
Required Response
103.6.17
103.7 103.7.1
103.7.2
103.7.3
Each bidder shall describe how local PDS will support this.
103.7.4
103.8 103.8.1
Each bidder shall describe the support to be provided for the selection of persons.
103.8.2
FINAL 1.0a
Page 52 of 607
ICRS
Requirement characteristics). 103.8.3 The service shall enable application of these selection criteria. The characteristics of persons used for selection shall be capable of being amended and extended. The service shall support criteria based on the recommendations of the Joint Committee on Vaccinations and Immunisations (JCVI) for children. These set out minimum and maximum ages for undertaking immunisations and the minimum interval that shall exist between each dosage. The service shall enable care professionals to identify every child within a school within an appointed age range, who is due for a health check, together with any children due for recall and any who were absent for a previous appointment. The service shall provide for the selection of children within schools for health interviews at specified ages (e.g., at age11+ years, calling all year 7 pupils who have not been selected for a school medical). Inviting Persons for Prevention and Screening and Booking Appointments The service shall enable the booking of appointments for prevention activities or screening for persons selected, by matching individuals to available screening appointments within the required timescale. For example, this will include: appointments at general practices for smears; appointments for retinopathy screening; and appointments vaccination. for immunisation and
Required Response
103.8.4
103.8.5
Each bidder shall describe how this specific selection process will be supported.
103.8.6
103.9
103.9.1
Each bidder shall describe the facilities for the booking of prevention and screening appointments, and in particular how generic eBooking services may be used to support this requirement.
103.9.2
The service shall enable the automatic production and dispatch of invitations to persons selected for prevention or screening. For example:
Each bidder facilities for invitations.
shall describe the the production of
FINAL 1.0a
Page 53 of 607
ICRS
Requirement for breast cancer screening, a specific appointment time shall be provided; and for cervical screening, the invitation may in some instances require the person to contact their general practice for an appointment.
Required Response
103.9.3
The service shall record the parent/carers wishes with regard to which immunisation a child is to receive, and shall enable care professionals to identify children for whom no such information is recorded. The service shall enable the parents or carers of children to be offered a choice of alternative centres, where their childs vaccination or immunisation shall be undertaken. The service shall enable individuals within certain target groups to be recalled regularly for screening according to user-defined protocols; for example, for children identified as being at high risk of developing hearing problems. The service shall support the scheduling of health checks at specified schools. These checks could include vision, hearing, height and weight, etc. These are group sessions and it shall be possible to allocate a maximum number to each session, reflecting the type of session. The service shall enable the despatch of selftesting kits to a persons home, and the tracking of the return of these for analysis (e.g., for bowel cancer). The service shall enable the monitoring and follow-up of non-response to invitations within specified time periods from the date of issue of the invitation. Each bidder shall describe how regular recall will be supported.
103.9.4
103.9.5
103.9.6
Each bidder shall describe how booking and scheduling modules may be used to support group sessions within schools.
103.9.7
Each bidder shall describe how selftesting will be supported.
103.9.8
Each bidder shall describe how monitoring and follow-up will be supported, and the extent to which this may utilise generic workflow support.
103.9.9
The service shall enable the identification of persons who have not yet been screened within particular time periods. This shall include neonates, who have not been screened within specific time periods from birth, in accordance with the protocols for specific programmes.
FINAL 1.0a
Page 54 of 607
ICRS
Requirement 103.9.10 The service shall enable capture of the details of invitations issued, responses and booked appointments within a comprehensive record for each person. The records must be capable of being accessed by other care professionals involved in the care of the person and the prevention or screening process. The service shall enable notification to responsible care professionals of outstanding non-responses to invitations. The service will link to external population records, from which target populations defined by universal characteristics, such as age and sex, may be identified for screening. Scheduling Resources to Enable Prevention, Screening and Surveillance Appointments and Activities. This is a specific instance of generic scheduling ordering and stock control requirements covered in Module 108 Scheduling. The service shall support the scheduling (and ordering) of resources (staff, facilities, equipment, vaccines/antigens and consumables) to enable prevention, screening and surveillance appointments and activities to be undertaken at a particular location, date and time. The service shall support the scheduling of immunisations at specified schools. Undertaking Prevention Screening Investigations Activities and
Required Response
103.9.11
103.9.12
103.10
103.10.1
103.10.2
103.10.3
103.11
103.11.1
The service shall enable the capture of details of attendance for vaccination, immunisation and screening, the activities undertaken (including tests, investigations, antigens administered, batch numbers, etc.) and the care professionals involved. This shall include a record of whether a parent or carer was present at an activity involving a child. The service shall enable the capture of details of non-attendance, notifying relevant care professionals and initiating follow-up and further invitations (reflecting national and local
Each bidder shall describe how the capture of prevention and screening details will be supported and if generic clinical noting support may be applied.
103.11.2
FINAL 1.0a
Page 55 of 607
ICRS
Requirement standards and policies). 103.11.3 The service shall enable the requesting of analysis of specimens, dispatching of these, and capturing full details of the request in a patient's record, ensuring that specimens are unambiguously associated with the person being screened and the request. (See Module 110 - Ordering, Requesting Services and Goods.) The service shall enable the monitoring of progress of the request for analysis and highlighting when the results are overdue (reflecting agreed performance targets for the analysis of tests/specimens) and what follow up actions are required. (See Module 110 Ordering, Requesting Services and Goods.) Modules of the standard NHAIS application currently support screening for breast and cervical cancer, and bidders should demonstrate how this support might be integrated within their solutions for care communities. Recording the Outcomes of Screening Investigations The service shall enable receipt of the results of analysis of specimens or of imaging undertaken and their inclusion within the persons comprehensive care record. (See Module 111 - Results Reporting.) This information shall be accessible to authorised care professionals who are responsible for the ongoing care of the person and are involved in the screening process or involved in subsequent assessment and treatment. This may either be as a result of this screening or, subsequently, when a disease is detected through other processes between screenings. 103.12.2 The service shall support the requirements of specific programmes for the capture and recording of the results of screening tests. For example, the results of neonatal biochemical screening, such as Phenylketonuria (PKU) and Thyroid Stimulating Hormone (TSH).
Required Response
Each bidder shall describe how generic ordering support may be applied to these programmes.
103.11.4
Each bidder shall describe how generic ordering support may be applied to these programmes.
103.11.5
103.12
103.12.1
Each bidder shall describe how generic results reporting support may be applied to these programmes.
FINAL 1.0a
Page 56 of 607
ICRS
Requirement 103.12.3 The service shall support the recording of details of assessments undertaken within regular child development interviews within schools. These details will include measurements (of height, weight, vision, hearing, etc.); whether the parent was concerned; whether the child was concerned; whether a problem was identified; and any subsequent referral. The service will have the ability to record other characteristics (such as lifestyle, family history, etc.), which may be factors in determining the risk of an individual developing a condition or problem, within Patient Records. Communicating and Acting on the Results of Screening and Surveillance The service shall stimulate clinician contact to provide notification of the results of a screening to the person screened. The form of notification will reflect the results and the specific programme; for example: for breast cancer screening, a positive result will be accompanied by details of an appointment for further investigation; for bowel cancer screening, a positive result will be accompanied by an appointment with a care professional to review the results; and for cervical screening, this will involve an appointment with a GP, which may lead to referrals for specialist assessment and diagnosis.
Required Response Each bidder shall describe how this will be supported and any use of generic assessment and care planning support.
103.12.4
103.13
103.13.1
Each bidder shall describe the facilities for notification of results.
103.13.2
The service shall support notification of the outcomes of screening or surveillance assessments to other care professionals; for example, to provide GPs with the results of school-based development assessments of children registered with them. The service shall enable care professionals to provide context-specific advice to teachers on the outcomes of development assessments. The care professional must be able to determine the content of this advice, which may be provided through controlled access to
103.13.3
FINAL 1.0a
Page 57 of 607
ICRS
Requirement a childs record or as a hard copy. 103.14 103.14.1 Quality Assurance of Screening Processes The service shall enable screening services and centres to be able to identify: those people who have had a disease diagnosed during the interval between screening tests; and those people who have had a disease diagnosed but, for various reasons other than eligibility for screening, have not been screened (e.g., they did not attend screening, have not been included in screening register, etc.).
Required Response
Each bidder shall describe approaches through which proposed solutions would facilitate such quality assurance.
103.14.2
The service shall enable the screening services and centres to access comprehensive records covering the screening history for these patients, to enable any quality lapses in either patient selection and invitation processes, or in screening, testing and analysis processes, to be identified. Abstraction and Reporting The service shall provide flexible data abstraction and reporting tools to enable the operational management of prevention, screening and surveillance programmes. Such tools shall enable the production of reports covering, for example, numbers of persons screened or assessed within particular time periods, or those with abnormal or normal results, listed or aggregated by (for example) GP, care team responsible, school, area of residence, etc. For neonatal programmes, the service shall provide facilities to monitor age of diagnosis, false positive referral rates, and the difference between the ages of diagnosis for high risk and low risk cases. The service shall be able to provide information to GPs and to the Primary Care/Care Trust on immunisations given for verification to support the payment of GPs Each bidder shall describe the information that might be provided. This should include details of date of administration of vaccines, a code to Each bidder shall describe how flexible abstraction and reporting will be supported.
103.15 103.15.1
103.15.2
103.15.3
103.15.4
FINAL 1.0a
Page 58 of 607
ICRS
Requirement under the GP contract for target payments. 103.15.5 The service shall support the calculation of "items of service" payment for GPs for those immunisations which fall outside the scope of "target payment." The service shall provide analysis and reporting support for the caseload management of teams of care professionals. The service shall have the ability to create registers of patients who are identified as fitting a defined cohort group. This will include: using the service to identify patients who meet certain criteria in order to populate a register, e.g. selecting patients who have met risk criteria for diabetes based on data held within their records. creating a register to which patients are added based on their requirement for particular service or specific characteristic, e.g. a learning disabilities register.
Required Response indicate location, and payment status.
103.15.6
103.15.7
FINAL 1.0a
Page 59 of 607
ICRS
104 - Assessment Overview This module specifies the requirements for the service to support all clinical assessments across all care settings, incorporating the specific requirements of the Single Assessment Process (SAP) - with links to social and other care agencies. ICRS seeks to address, specifically, the generic functional requirements that arise from the distributed nature of care services and the need to deliver patient -centred, integrated, evidence-based care. NSFs are driving the latter and require the development of increasingly shared (integrated) assessments and care planning within and between services. Assessment is critical in the care process and can take a number of different forms, including one-off assessments that are conducted as part of a GP consultation, for example, or a complex series of assessments that form part of the review process within a care plan or care pathway. Assessment forms part of the care process for a majority of health and Social Care professionals, including doctors, nurses, social workers and physiotherapists to name but a few. The assessment criteria which are used will be different for each of these disciplines, and the solution will need to accommodate this level of diversity; allowing for significant local control in tailoring the design and operation of the assessment function, which will include the integration of rules-based intelligence. At the same time, the solution must support the sharing of common assessment information to ensure that the same information is recorded once and shared. Scope Support for the documentation of uni- and multi-disciplinary assessments in a structured form; e.g., templates linked to the Patient Record. Support for integration of structured assessments within care plans and care pathways, as required. Support for access to assessment documentation. Support for access to clinical knowledge; e.g., guidelines and protocols to be available during assessment (a specific example of Module 105).
Components Structured assessment templates for specific types of clinical assessment, with the ability to create and amend templates (including an Audit Trail for amendments). Common data dictionary of data items to enable sharing of common information across each assessment template. Incorporation of different types of clinical assessment and evaluation information, including graphical, textual, numeric, audio and video data.
Exclusions It is not intended to define the specific requirements for assessment provided within a single service, such as Primary Care. Protocol management (see Module 112).
Benefits and Outcomes Current Situation Typically, there will currently be: multiple assessments, with more than one person collecting the same information;
FINAL 1.0a
Page 60 of 607
ICRS
integrated teams that are not supported by an integrated operational information support system; and duplicate investigations.
Desired Benefits and Outcomes To: Patient Improved assessment experience for patients who are not required to provide the same information for different services. More integrated care. No unnecessary investigations. Supports better patient care by invoking consistent, evidence-based, structured assessment for each clinical discipline. Clinician Save time through removal of duplication in clinical documentation across care settings. Better support for multi-disciplinary care. Opportunities to improve current ways of working. Assessment information can be shared between the services and can thus assist the development of more efficient assessment procedures. Reduces risk of litigation through the application of a structured assessment process, which reduces the chances of missing critical information, and sharing of assessment information across healthcare settings and disciplines. Common assessment tool across all healthcare settings and disciplines will encourage better multi-disciplinary working, and may reduce the requirement for multiple assessment templates. Manager Improved reporting on service delivery.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) The development of facilities to migrate current paper-based multi-disciplinary assessments to electronic formats, store any current electronic based assessment and receive any electronic assessments from current systems. All Clinicians to have the facility to electronically view current assessments. Minimum Level to Be Achieved by December 2006 (Phase 2) All Clinicians to have the facility to electronically document uni- and multi-disciplinary assessments. Target for 2010 Assessment to be fully incorporated within Integrated Care Pathways where relevant and documentation/communication is provided as an automatic by-product of providing care. LSPs are invited to state any ability to deliver in excess of this minimum within the time frames stated.
FINAL 1.0a
Page 61 of 607
ICRS
Overview Requirements Requirement 104.1 Overview The core requirement is a system which allows a group of Clinicians to create, maintain and view assessment information about a patient in a collaborative, multidisciplinary manner. 104.2 Benefits and Outcomes As described above. 104.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. Required Response Each bidder shall describe its approach to delivering the support for multi-professional assessment.
Each bidder shall describe how it would deliver the benefits and outcomes from this module. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
104.4
Detailed Requirements Requirement 104.5 104.5.1 Assessment This function involves the collection of information from a range of sources in order to build a profile of a patients overall care needs; identify a patients clinical problem, including preliminary and confirmed diagnoses; and to review progress as part of a plan of care. This can be in a multi- or unidisciplinary context. This facility shall enable the collection of structured and, in some cases, free-text assessment information to enable more complete and consistent information to be collected and shared. It shall provide improved access to assessment records for appropriate staff. 104.5.2 Assessment requirements will differ widely between healthcare professional groups; for example, between nursing staff (who will Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches. Required Response
FINAL 1.0a
Page 62 of 607
ICRS
Requirement require assessment facilities to be closely integrated with care planning) and therapy staff (who will be assessing the patient in response to a referral). Assessments will also contain a variety of types of data; for example: observations, such as temperature or blood pressure; risk assessments, such as pressure sores; and information related to home circumstances, social support, etc. The LSP is required to describe the assessment facilities provided by the system in full, highlighting how these can meet the different requirements described above, and any areas that are not currently supported. 104.5.3 The service shall allow information concerning assessments for a patient to be recorded, including problems and causes, diagnoses and supporting clinical notes. The service shall allow an assessment to be linked to a care Episode. The service shall support the recording of assessment details against a Patient Record using locally-defined templates, or national templates where they exist. The service shall support inter-disciplinary and inter-agency assessments; e.g., allowing contributions from different staff groups, such as Social Services staff, medical staff and nursing staff to be combined within the same assessment. The assessment facility must be capable of deriving dependency/severity indices from the data entered. The service shall support Clinicians applying systematic assessment tools. in
Required Response
104.5.4
104.5.5
104.5.6
104.5.7
104.5.8
The service shall support the Single Assessment Process. For older people, the domains of the Single Assessment P rocess shall form a basis for the assessment of their needs. Assessments will be created individual Clinicians and by teams. both by
104.5.9
104.5.10
Assessment will form part of treatment and care plan functionality and ICPs. Assessment functionality shall therefore be incorporated
Each bidder shall describe how the assessment function operates as a core function of the LSP Services,
FINAL 1.0a
Page 63 of 607
ICRS
Requirement within these components as required. In particular, it shall use the same terminology, measurement units, etc. 104.5.11 The service shall provide access to caseload/resource information and waiting list information to enable effective decision making following assessment based upon availability (including timely response to service request), skill set, professional role, caseload weighting, and patient choice/needs. This may be in the form of a worker matrix, detailing the items above. The service shall provide access to previous assessments. The service shall provide easy access to assessment information and assessment summaries, both for individual staff members and, where appropriate, other members of the team. The service shall provide on-line access to appropriate policies, procedures, care protocols, guidance, etc., and have the potential to provide active clinical decision support; for example, by comparing entries made by staff with guidelines and protocols. The service shall support interfaces to systems that provide Clinicians with information to assist with the initial assessment, such as analysis of samples or investigative tests. The service shall be integrated with the eBooking service when it becomes available. The service shall support the receipt of results of tests and assessments undertaken by other care professionals, including notifications to indicate results received and automatic association with Patient Records. Any patient input to the assessment process shall be recorded and flagged. This may be in the form of self-assessment questionnaires, or feedback/comments on assessment activity and will include assessment for patients who self-refer.
Required Response as well as being incorporated as an integral part of a care pathway or care plan.
104.5.12
104.5.13
104.5.14
104.5.15
104.5.16
104.5.17
104.5.18
FINAL 1.0a
Page 64 of 607
ICRS
Requirement 104.5.19 Patient interaction may be necessary with certain assessments; eg CLOX tests. The service shall support the production of hard copies of assessments, including formats suitable to specific users (like large print, voice output and braille). The service shall support nationally- and locally-defined protocols, templates and guidelines for data entry and decision support. Links to outside repositories of information, as to how assessments and tests shall be interpreted, shall be present. The service shall support the multi-disciplinary decision approach to assessing appropriateness of a referral and determining the most appropriate care professional or group to undertake future action. The service shall provide access to all the required records on the system, subject to the requestor's discipline. The service shall record information in coded form (e.g., SNOMED CT) where appropriate for subsequent analysis. Numerical data shall be tabulated or graphed, as a single assessment and in the format of a sequential plot, to display changes in outcome measured alongside various interventions, medication types or changes, and significant events. The service shall display data trends across assessments over time in different formats; e.g., graphical and textual. The service shall maintain an Audit Trail to identify when changes were made and by whom. The service shall, where required, notify external professionals involved in the care of the patient, such as GPs, community staff and Social Services staff, that an assessment has occurred, including communication of selected details from the assessment.
Required Response
104.5.20
104.5.21
104.5.22
104.5.23
104.5.24
104.5.25
104.5.26
Each bidder shall describe how the solution supports the comparative review of assessment information over time.
104.5.27
104.5.28
104.5.29
FINAL 1.0a
Page 65 of 607
ICRS
Requirement 104.5.30 The service shall link between a Clinician's diary or diary function and caseload weighting information to indicate worker availability and appropriateness. When the most appropriate Clinician has been identified, a service shall support the process that leads to the completion of the assessment. Intra-team referrals shall be automatically triggered should the identified clinician no longer be the most appropriate e.g. in case of illness or resignation. Additional assessments shall be supported as part of care co-ordination, and if specifically requested within the Single Assessment Process. The service shall support revision of these assessments, and this may indicate a link to national centres of excellence or repositories for specialist information; e.g., NELMH. The functionality described to support, review and amend additional assessments shall ensure that other care models' processes are supported; e.g., substance misuse. The service shall support the creation of overall assessment and review processes, including the identification of the current stage the patient is at within the overall processes, and provision of information which will support care professionals in monitoring the progress of the processes without unnecessary delay. Risk Assessment The service shall support the recording of risk assessment for patients at higher risk, such as older people or mental health patients. This assessment shall link with risk management incorporated within the care plan or care pathway; e.g., triggering of an alert to a Clinician if an at-risk mental health patient fails to attend an out -patient appointment. Risk assessment outcomes shall link with system-generated prompts and the care planning stages. The functionality required would ensure that elements of risk are not overlooked but are planned for appropriately.
Required Response
104.5.31
104.5.32
104.5.33
104.5.34
104.6 104.6.1
Each bidder shall describe how risk assessment is incorporated within their p roposed solution and identify how this links with risk management.
104.6.2
FINAL 1.0a
Page 66 of 607
ICRS
Requirement 104.7 104.7.1 Carer Assessment Standard Six of the NSF for Mental Health, "Caring about Carers" and the Carers and Disabled Children Act 2000 highlight the need to ensure that all carers are assessed for their caring, physical and mental health needs at least annually. The service shall support the assessment of carers and identification of the link between a carer and patients. This shall also be available for carers who are not registered on the MPI. Reporting The service shall produce summary and multiand uni-disciplinary assessment reports, allowing the user flexibility in selecting the information that appears on these reports and the format of the reports. Further Requirements The service shall demonstrate the ability to identify, attribute and track changes to assessments. The service shall enable access to previous assessments. The service shall include rules based intelligence from within the assessment function which will trigger other functions such as care planning, risk assessment, onward referral, self-harm intention, prompts to provide patient with printed information, scheduling of review dates and prompts to remind of scheduled review dates etc. The service shall provide the ability to produce summary assessment details for use in an emergency or high volume environment. Multi-professional assessments which straddle different organisations particularly health and social care shall require different formats. Social care assessments which form part of SAP are likely to be in text format which may be presented as a digital scanned document or as a semi structured form. The service shall accommodate different formats within the same multi-professional
Required Response
Each bidder shall describe how assessment of carers can be supported by the solution, and indicate how carers are linked to patients and identified on the system.
104.8 104.8.1
104.9 104.9.1
104.9.2
104.9.3
104.9.4
104.9.5
Each bidder shall describe how integrated multi-professional assessments such as SAP which incorporate various components in different formats can be accommodated within ICRS.
104.9.6
FINAL 1.0a
Page 67 of 607
ICRS
Requirement assessment. This will include an ability to upload documents created on word processors as well as scanned documents. These documents need to be referenced within the assessment record using document management standards (see module 116). 104.9.7 The service shall be able to retrieve assessment documentation or data which resides in external systems and embed them in the assessment record, including workflow tasks. The service shall provide the ability to save incomplete assessments (i.e. where data is unavailable) and edit them later. The service shall be able to confirm completion of an assessment after which editing will o nly be possible under strict audit control. The service shall be able to identify the staff member responsible for co-ordinating the care to which the assessment relates. The service shall enable multi-disciplinary assessments to be summarised in an overall assessment. The service shall support a virtual case conference capability, audio, video or secure chat room as part of the assessment process. Where more than one Episode of care is currently open the service shall alert the assessor to all other assessments. Health and social care professionals are often required to input into other assessments which may not be part of the ICRS record. For example Clinicians need to input into an education needs assessment. Given the large number of assessment templates that will be incorporated within ICRS, the service shall ensure that users are provided with drop down lists of their commonly used assessment templates/formats.
Required Response
104.9.8
104.9.9
104.9.10
104.9.11
104.9.12
104.9.13
104.9.14
Each bidder shall describe how this process could be supported by ICRS.
104.9.15
FINAL 1.0a
Page 68 of 607
ICRS
105 - Integrated Care Pathways and Care Planning Overview This module specifies the requirements for the service relating to Integrated Care Pathways and care planning. It also includes a sub-section relating to CPA (Care Programme Approach for Mental Health). It is intended that the functionality provided to support care plans, care pathways and the CPA process will be generic but applied in different ways according to clinical requirement. An Integrated Care Pathway or ICP describes a process within health and Social Care, which maps out a pre-defined set of activities and records care delivered and the variations between planned and actual care. ICPs will be used to support "whole systems" processes spanning Primary Care and Secondary Care service boundaries. ICPs are largely based on conditions or diagnoses. The development of ICPs is a complex process and, from a clinical perspective, will take time to develop. The current reliance on paper-based care pathways has made the task of defining pathways of care more difficult in terms of design and application as a real-time tool to assist in delivery of evidence-based care. The incorporation of ICPs within the LSP Services will enable ICPs to become an active tool to assist in the delivery of care; incorporating clinical decision support to identify actions, reminders and guidance at the point of care, across the continuum of care. It is recognised, however, that the development of active, multiprofessional ICPs will take time to create and apply. In the meantime, the planning of care still needs to be supported for specific disciplines and across disciplines where planning is already used. Support for care planning has therefore been defined as a requirement of the LSP Services. It should also be noted that care plans, within the context of Integrated Care Pathways, are constituent elements of ICPs, so there is a relationship between care plans and ICPs which will necessitate the use of generic tools to set up and manage care plans and pathways to enable distinct plans to be nested within ICPs. The Care Programme Approach for Mental Health defines a broader mechanism of structured care, incorporating all aspects of a patients health and well being. This includes close interaction between health services and Social Services in defining needs and ensuring these needs are met. The requirements of the electronic CPA (eCPA) have therefore been incorporated within this section. Given the current move to a more holistic "care co-ordination" approach to care provision, in which the patient has a greater decision making role, particularly for areas such as care of the elderly, the application of tools which will support eCPA may well be applied to other clinical areas. The concept of care co-ordination can be regarded as the frameworks of Care Programme Approach, care management, the Single Assessment Process, and all other frameworks which seek to formalise the process of assessment/planning/intervention/evaluation. The approach used is patient-focused in all instances, as it is the patients pathway through the services. The description of the eCPA and care management process is found within Module 161 - Mental Health. The specific requirements above and beyond those identified for care planning and ICPs are defined in this module. Integrated Care Pathways There is a generic ICP standard model which identifies the essential component parts and functionality of a care pathway. Care pathways have three states of use: model care pathway is a useable version of an agreed, referenced and authored care pathway (containing the care and activities intended or recommended, objectives or expected outcomes and patient data to be collected). It is a structured piece of knowledge; care pathway in use is a model care pathway being applied to a specific patient and health issue, in real time, to record patient information, including variances and exception reporting; and
FINAL 1.0a
Page 69 of 607
ICRS
ended care pathway is the final use state of a care pathway for a patient; whether the care pathway was completed, abandoned or discarded (i.e., considered but never initiated). This resultant care record provides a structured set of data for local and national audit, clinical governance and analysis.
Treatment/Care Plans A care plan is the result of the assessed needs of an individual and the planning process to redress those needs. A care plan needs to have at least one objective. All interventions need to be planned to meet these objectives/aims or a stage towards them. Interventions are the planned activity put in place to affect a change in a persons health or social circumstances. They could also be classified as packages of care provided by other agencies or organisations. Formal evaluations of a patients care will occur both on a planned and an ad-hoc basis. The review of care may be either uni- or multidisciplinary. The review will involve comparing the patients current condition against the goals and objectives set in the treatment/care plan and may also identify a change in need which necessitates a change to the care pathway/plan. Produce Treatment/Care Plans Treatment/care plans describe the characteristics of the treatment or care which is being provided (or will be provided) to address the patient needs and objectives identified by the assessment. Typically, a plan would give details of the type of treatment/care, the professionals or others involved, and the frequency of any interventions or reviews. The service shall provide functionality to support treatment/care planning, in accordance with emerging local and national guidelines and standards, For example, the document, "Getting the Right Start" (available at the URL, <http://www.doh.gov.uk/nsf/children/hospitalstandard.pdf>), details guidelines regarding the discharge of children about whom there are possible child protection or other concerns. To address the more complicated needs of some patients, there may be a need for several care plans. For example, for multi-disciplinary cases, there may be a high-level care plan which describes the overall care to be provided across the various disciplines, with each individual discipline involved producing a more detailed uni-discipline care plan to address each individual need. Scope Integrated Care Pathway Components Model Care Pathway Is version controlled and has a life cycle for being authored, piloted, published and reviewed. Specifies a health or social care issue and the expected, associated patient characteristics and symptoms. Contains or has links to guidelines, protocols and other relevant evidence. Contains activity or intervention specifications, along with valid activity state change and role specification. Contains an expected overall objective and specific patient objectives.
FINAL 1.0a
Page 70 of 607
ICRS
Care Pathway in Use Contains information about the patient demographics, patient characteristics (history, presenting problem, observations) which may or may not be as expected from the model care pathway. Contains the care plan, as agreed (or for which consent has been obtained) and tailored for the patient; the activities or interventions carried out as scheduled or altered; and any reasons for variance, ranging from staff or equipment being different or not available to changes in the patients condition. Contains the specific patient outcome resulting from activity being carried out.
Ended Care Pathway Contains a record of variance between what was expected (in terms of patient characteristics and outcomes, activity and valid activity states, and who performs an activity and when) to what actually happens. Provides a record of the application of a particular version of a care pathway to a patient, whether the care pathway is completed in its entirety or only considered or partially completed.
ICPs - Other Functionality Provides the capability to merge care pathways and to produce a single care plan (or work list) for the patient, or to enter into, suspend or exit a particular care pathway as required. See Module 112 Assessments and Care Planning. Provides the means to identify who has overall responsibility of care, whether the patient is on one care pathway or a combination of several at any point in time. Provides the ability to schedule people and resources across multiple organisations. Enables the patient and/or carer to receive a copy of their care pathway.
Exclusions This module does not address ordering functionality (see Module 110 Communications) that would need to interface with carrying out a specified activity. - Order
It does not specify actual data items; only the type of information and how it relates between classes of data. It is not intended to define the specific requirements for care planning provided within a single service such as Primary Care. Protocol management (see Module 112 - Decision Support).
Scope - Care Planning Support for the documentation of uni- and multi-disciplinary assessments and care plans in a structured form. Support for access to assessment and care planning documentation.
FINAL 1.0a
Page 71 of 607
ICRS
Support for review of care plans. Support for access to clinical knowledge; e.g., guidelines and protocols during assessment and care planning (a specific example of Module 112 - Decision Support).
Components Care planning. Review.
Benefits and Outcomes Desired Benefits and Outcomes To: Patient Improved organisation and continuity of care. Avoidance of duplication of effort. Involvement of the patient in the planning of care. Use of evidence-based, locally-agreed best practice. Provision of integrated services from more than one organisation. Provision of a manager to monitor and record progress against an ICP/care plan. Receipt of a printed or electronic copy of own ICP/care plan. Clinicians and Social Care Professionals Availability of patients record on-line for viewing. Capture of clinical terminology and codes to improve quality and to aid subsequent analysis. Availability of the most up-to-date guidelines and best practice. Ability to feed into the development process to provide continual improvement. Ability to monitor progress along a care pathway. Ability to measure deviance from a care pathway with a record of the reasons for that deviance. Ability to integrate local and national standards. Ability to document by exception. Manager Improved ability to plan and measure the use of personnel and resources. Ability to measure the difference between planned and actual care. Delivery of more standardised care, linked to protocols and treatment plans. Redesign of health care delivery made possible, thereby avoiding safety and quality risks posed by existing outmoded ways of working. Ability to continually improve care pathways. Ability to document by exception.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Care pathways are essential to support the service changes envisioned in the NHS Plan and GMS Contract. This functionality is needed to support the role of GP specialists and intermediate care teams in providing integrated care to patients.
FINAL 1.0a
Page 72 of 607
ICRS
Ability to construct, modify and use ICPs to support the aims of the hospital improvement partnership. There is a requirement by 2005 to record total journey time from a GP referral to discharge, back to the GP after treatment, and follow-up care. The development of facilities to migrate current paper-based multi-disciplinary care plans. All Clinicians and Social Care professionals to have the facility to view current care plans. Minimum Level to Be Achieved by December 2006 (Phase 2) Inclusion of basic component parts of ICPs; i.e., model care pathway, care pathway in use, and ended care pathway. All Clinicians and Social Care professionals to have the facility to document uni- and multi-disciplinary care plans. Target for 2010 Full functionality as described in all sections of the requirements. Care planning is co-ordinated through ICPs and documentation and communication is provided as an automatic by-product of providing care. Bidders are invited to state any ability to deliver in excess of this minimum. Detailed Requirements Requirement 105.1 Overview Required Response Each bidder shall describe its approach to delivering the required components of ICPs and scheduling within ICRS. Identify any requirements or limitations that might apply to integrating the functionality of ICPs and scheduling services with other components of ICRS. 105.2 Benefits and Outcomes The expected benefits and outcomes have been set out above. 105.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 2 functions. Describe what functionality could be delivered within Phase 1. Each bidder shall describe which additional functions it would be able to deliver by 2010.
FINAL 1.0a
Page 73 of 607
ICRS
Requirement 105.4 Authoritys Responsibilities
Required Response The bidder must describe the responsibilities it would expect to be assumed by the Authority.
Detailed Requirements Requirement 105.5 Model Care Definition Pathway/Care Plan Required Response
105.5.1
The service shall provide the ability to create, maintain and manage care pathways and care plans.
Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
105.5.2
The service shall provide version control, allowing the creation, monitoring and recording of changes in design to ICPs and care plans, as well as baselining, version-tracking and revision summaries. The service shall provide the ability to incorporate clinical decision support in identifying and invoking workflow, alerts, reviews and activation of guidelines as part of the care pathway or care plan, set up and operation. The service shall provide the ability to maintain an electronic history or library of care pathways and care plans and component parts; i.e., care plans, units of care/activity. The service shall support the life-cycle for creating a care pathway or care plan, including: piloting, publishing and reviewing it; and abandoning or withdrawing it. It shall also enable the identification of who shall carry out specific activities, their organisational roles, and the professionals who contribute to the publication and its review and who have responsibility for it. The service shall provide clear identification of the component parts and the interrelationship between them;
105.5.3
105.5.4
105.5.5
105.5.6
FINAL 1.0a
Page 74 of 607
ICRS
Requirement i.e., the inclusion or reference to particular guidelines or locally-accepted protocols. 105.5.7 The service shall provide explicit links to internal and external Web-based resources. The service shall enable the inclusion of help information in using the care pathway or care plan. The component parts potentially reusable. shall be
Required Response
105.5.8
105.5.9
105.5.10
The service shall provide a health issue specification with required patient characteristics and overall objectives. The service shall provide activity specification with clear, valid activity state types which explain the order in which interventions shall be carried out or the conditional states that need to be present in order to proceed. The service shall provide identification of what type of Clinician and/or level of skill is required to carry out a specific activity. Care Pathway in Use (Applied to Patient) The service shall provide a record of an individual patient's details demographics, assessment, history, diagnosis or provisional diagnosis and presentation -- as specified by the model care pathway and relevant NSFs. The service shall provide a clear means for obtaining patient consent to the care that is agreed, whether as specified by the model care pathway or for any deviation from it that is required. The service shall p rovide the ability to create a unique, individualised plan of care, the model care pathway providing guidance in establishing the individual care plan. The plan can be created using a range of criteria such as Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
105.5.11
105.5.12
105.6
105.6.1
105.6.2
105.6.3
FINAL 1.0a
Page 75 of 607
ICRS
Requirement patients choice, cost, availability, etc. 105.6.4 The service shall enable an individuals care pathway to include component parts of other care pathways, or contain activity completely unique to the individual which is not already established as part of a care pathway (e.g., use of a particular relaxation technique prior to surgery). The service shall provide the ability to place a patient on a number of care pathways. It shall also be possible to check and warn of issues arising from the coexistence of care pathways for a given patient. Where a patient is on more than one pathway, there shall be a check for conflicts and divergence. There shall be checks that duplicate tests are not requested by each pathway. 105.6.6 The service shall provide the ability to print out or view components of care, whether this is according to professional type, time (e.g., drugs to be administered at 1.00 p.m.), or type of intervention. The service shall provide the ability to identify the resident medical officer and other roles, as well as changes in responsibility for care. The service shall provide the ability to automatically record the identity of each user who has provided input to, evaluated or amended the care plan. The service shall support digital signatures denoting clinical authorisation, acceptance or confirmation, in accordance with the care pathway or care plan. The relationship between component parts shall support logical, required recording. For example, where medication has been withheld due to nausea and vomiting, then, for the component part which is the activity of
Required Response
105.6.5
105.6.7
105.6.8
105.6.9
FINAL 1.0a
Page 76 of 607
ICRS
Requirement giving medication, the user should be able to record that the activity was "not done due to"; while the component part which is the patient characteristic should allow the recording of "nausea and vomiting". 105.6.10 The service shall support the monitoring of actual health outcomes against expected outcomes, identifying variations. The service shall support the recording of activity as completed, stating by whom and at what time it is completed. The service shall be able to alert Clinicians to outstanding activities, or activities requiring intervention which are outstanding, or where further action is required. The service shall enable dependencies between specified critical activities to be defined, such that warnings are built in to inform staff that certain activity must be completed before further activities can commence. The service shall cancel future critical activities if the patient is deceased, so that other clinical specialties can cancel placed orders, withdraw case notes, etc. An ICP and the underlying activities/schedules shall terminate appropriately upon notification of patient death. Scheduling and ordering investigations, drugs, etc., shall be initiated from the care pathway and are integral to the care planned for and provided. Activities, such as repeated assessment and on-going monitoring, shall be part of standard functionality. An activity shall be carried out as long as a particular condition exists. The service shall enable the recording of an individual patient's outcome or change in condition, which shall be linked to an activity if required (e.g., if a
Required Response
105.6.11
105.6.12
105.6.13
105.6.14
105.6.15
105.6.16
105.6.17
FINAL 1.0a
Page 77 of 607
ICRS
Requirement patient is no longer experiencing nausea one hour after receiving a certain medication). 105.6.18 The service shall provide the ability to view information at a summary level. The ability to drill down in detail is required. The service shall enable a care pathway to be suspended or delayed, and the patient placed on an alternative one, as required during the same Episode of care. Any immediate change to the care plan shall be recordable and integrated into the care pathway. The services shall provide the ability to capture actual service delivery during a period, and compare it with the care plan/pathway. The Ended Care Pathway The service shall enable the recording of variance, and the association between what is expected and what actually happened. It shall account for: differences in expected patient characteristics for a health issue from how the patient presented; differences between patient objectives for a health issue and specific patient outcomes; differences between specified activity and what actually happened; whether the sequence or the conditional state differed, was abandoned or not required or refused, or other activity was added; and differences in who carried out the activity by regard to a specified role (e.g., teaching usually done by a diabetic specialist nurse was carried out by a junior doctor). The service shall provide the ability to manipulate any component of data for purposes of analysis, particularly key events. The service shall enable the identification of any deviation from tolerances associated with activity, patient characteristics, outcomes or the
Required Response
105.6.19
105.6.20
105.7 105.7.1
105.7.2
105.7.3
FINAL 1.0a
Page 78 of 607
ICRS
Requirement performer of an activity. 105.8 105.8.1 ICPs Other The service shall provide a means of integrated, multi-disciplinary record keeping.
Required Response
105.8.2
The service shall enable continuous refinement of the care pathway and the identification of the training needs of users. The service shall provide incorporation of clinical noting functionality (as defined in Module 106 Clinical Documentation), as part of the care pathway. ICPs Reporting and Data Export The service shall be able to produce the following reports: statistics relating to any sections of a care plan/care pathway; e.g., incidence of i fection, incidence of n pressure sores, and the number of patients who had a fall; an audit of the care plan/care pathway process, identifying for all patients: date of admission, date of care plan/care pathway creation, date care plan/care pathway last amended, and the number of outstanding and complete evaluations; a list of all patients with an evaluation specific to a goal due on a selected date; and the analysis and reporting of variance data. Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
105.8.3
105.9 105.9.1
105.9.2
It shall be possible to select and view details of all patients who are or were on a specified care pathway within a specified time frame. It shall be possible to produce patient information leaflets on the care to be provided, linked to appropriate
105.9.3
FINAL 1.0a
Page 79 of 607
ICRS
Requirement knowledge sources. 105.9.4 It shall be possible to produce userdefined outputs for the patient, including information about the care plan or care pathway as a whole, or specific aspects of the treatments to be received. The extraction of data from a patients record shall be supported to ensure that management and operational reporting responsibilities are fulfilled. The service shall be capable of producing a wide range of reports, from nationallymandated reports to locally-defined reports. Operational reports shall be produced for individual teams; e.g., lists of outstanding/overdue actions, service response times, and numbers of activities broken down by various categories. The service shall provide reports to monitor activity on individual patients. The service shall provide ad-hoc reports on medication or other information across the whole system (e.g., to find all patients on a specific drug). The service shall provide reports required by service managers for planning and monitoring purposes. This will include outcome-based performance reporting. The service shall provide or link into systems providing information relating to complaints received about services provided, including: date; time; the complainant; the other people involved; a description of the incidents causing the complaint; and any action taken. The service shall provide or link into systems providing information relating to incidents. The service shall provide or link into systems providing information relating
Required Response
105.9.5
105.9.6
105.9.7
105.9.8
105.9.9
105.9.10
105.9.11
105.9.12
FINAL 1.0a
Page 80 of 607
ICRS
Requirement to clinical governance. 105.10 105.10.1 Care Planning Treatment/care plans describe the characteristics of the treatment or care which is being provided (or will be provided) to address the patient needs and objectives identified by an assessment. Typically, a plan would give details of the type of treatment/care, the professionals or others involved, and the frequency of any interventions or reviews. To address the more complicated needs of some patients, there may be a need for several plans. For example, for multi-disciplinary cases, there may be a high-level plan which describes the overall care across the various disciplines, with each individual discipline involved producing a more detailed uni-discipline plan to address each individual need. 105.10.2 The service shall support the development of care plans which have the following characteristics: they are multi-disciplinary and may involve care inputs from several different agencies (including the patient and their family); they have both overall objectives and targets and specific ones relating to the inputs of specific care professionals; they have milestones and review dates; and they may comprise housing, education, employment and welfare components, as well as health and Social Care components.
Required Response
Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches. Each bidder shall explain how plans will be integrated if they are only offering partial solutions or if some of the patients care is outside the LSP's scope of responsibility.
They may have a "crisis" component detailing care inputs required if a patient presents in emergency circumstances. 105.10.3 The service shall provide access to historic treatment/care plans. The service shall enable the recording and maintenance of care plans in a uni-
105.10.4
FINAL 1.0a
Page 81 of 607
ICRS
Requirement and multi-disciplinary context. 105.10.5 The service shall provide seamless access to all the required records on the system, irrespective of the discipline from which access is sought, subject to authorisation. The service shall automatically link each treatment/care plan to the appropriate Episode of care / health issue, and shall allow for the development of both uni- and multidisciplinary treatment/care plans. The service shall record goals and objectives, and allow for timescales and anticipated outcomes, in coded form for subsequent analysis. The service shall be able to record the patient's and carer's input and opinions into the treatment/care plan, including consent to treatment. The service shall enable users to book appointments into diaries and clinic schedules and produce the appropriate notification for the patient (and other professionals and services) as appropriate. The service shall be capable of automatically assigning review dates. Note that this facility shall be optional for users or may alternatively assign maximum or minimum review periods (i.e. patient to be reviewed within 6 months). The service shall enable the updating of treatment/care plans, identifying when any changes were made and by whom. The service shall facilitate the maintenance of statutory registers, such as, but not limited to, the Child Protection Register, the Cause for Concern Register, the Disability Register, the Oxford Regional Impairment Register, the National Joint Registry, etc.
Required Response
105.10.6
105.10.7
105.10.8
105.10.9
105.10.10
105.10.11
105.10.12
FINAL 1.0a
Page 82 of 607
ICRS
Requirement 105.10.13 The service must support discharge planning to ensure multi-agency support is planned and co-ordinated appropriately. This is particularly important for children who are considered to be at risk, who must have a multi-agency action plan agreed between the NHS and Social Services, and in respect of whom the safety of the home environment must be checked before the child may be discharged. No child can be discharged from hospital without a documented plan for their future care, including follow-up arrangements. The service shall support the identification of key workers and care managers, allow them to be changed over time, and keep a record of previous position-holders. Note that a key worker and/or care manager is not assigned in every case. The term, "care manager", is used more commonly in Social Services. The service shall enable the printing of both full and summary treatment/care plans. The print facility shall be flexible to allow the user to select exactly what is printed at the full and summary levels. The format of the printed summary shall also be variable, to allow users with special requirements to read their care plan (large print, Braille, etc.). 105.11 105.11.1 Review of Care Plan Formal evaluations of a patients care will occur both on a planned and an ad hoc basis. The review of care may be either uni- or multi-disciplinary. The review will involve comparing the patients current condition against the goals and objectives set out in the treatment/care plan. The service shall facilitate easy access to details of care delivered to the patient so that it can be compared against the treatment/care plan. This includes access to assessment details, details of
Required Response
105.10.14
105.10.15
105.11.2
FINAL 1.0a
Page 83 of 607
ICRS
Requirement care delivered, and the treatment/care plan, both uni- and multi-disciplinary. Some of these comparisons may involve comparison of numerical scores/indicators and also coded fields (e.g., Bartel, Waterlow scores and neuropathy). 105.11.3 The service shall enable the recording of outcomes via locally- and nationallyprescribed methods. The service shall be capable of capturing review details in both coded and unlimited free-text format. Structured data collection shall be encouraged. The service shall allow a reviewer to record new findings, developments or care needs which will inform future care requirements and which will be fed into care plans. The reviewer shall also be able to remove satisfied needs from the care plan. Care Programme Approach The requirements of the Care Programme Approach and care management are core to the delivery of mental health services. Electronic care management must therefore be supported by the LSP Services. It is envisaged that generic functionality, such as assessment, care planning and review are used to support electronic care management. There are some specific requirements which have been identified below in supporting electronic care management. 105.13 105.13.1 Allocation for Initial Assessment The service shall support the collection of caseload/resource information to enable effective decision-making, based upon availability (including timely response to a servi ce request), skill set, professional role, caseload weighting, and patient choice/needs. This may be in the form of a worker matrix detailing
Required Response
105.11.4
105.11.5
105.12 105.12.1
FINAL 1.0a
Page 84 of 607
ICRS
Requirement the items above. 105.13.2 The service shall record assessment information using the Health of the Nation Outcome Scales (HoNOS) or similar outcome scales. This information will be produced at several stages of the process, and it must be possible to retain and review a history of the assessments to be included in subsequent views of documents. Outcome recording should be able to be viewed graphically where appropriate. 105.14 105.14.1 Assessment The current CPA processes supports the integrated processes of CPA and Care Management and includes a number of forms concerning assessment. The service shall enable the equivalent documentation functions to be performed and information recorded. For example, this may include detailed risk assessment and completion of a risk profile form as part of the assessment process. Risk assessment and the management of risk is a critical requirement of mental health care and will apply to other care groups as well, such as elderly care. The service shall support risk assessment and risk management through the use of specific assessmentbased tools which incorporate rulesbased intelligence to control the activation of alerts and warnings. This will include notification of a missed outpatient appointment to appropriate Clinicians. Standard Six of the National Service Framework for Mental Health, Caring about Carers, highlights the need to ensure all carers are assessed for their caring, physical and mental health needs at least annually. The ability to record assessment information for carers and assignment of carers to patients shall be supported.
Required Response
105.14.2
105.14.3
FINAL 1.0a
Page 85 of 607
ICRS
Requirement 105.15 105.15.1 Review The service shall include facilities to ensure that review dates are set in all cases where they are required, to prompt for due/overdue reviews, and to monitor the planning of reviews against the policy of the service in line with mandatory Department of Health reports. The production and collection of reports or feedback shall be supported to inform the review process prior to any review meeting. Orders to produce these reports/feedback shall be generated by the system, including patient or carer feedback. The service shall enable the recording of outcomes via locally- and nationallyprescribed methods. Care Co-ordinator/Resident Medical Officer The activity of recording who is the care co-ordinator or resident medical officer shall indicate who has responsibility for co-ordinating the care provided and when this responsibility started and finished. It shall be possible to specify at a local level which level/grade/other attribute of health and Social Care professional can act within this role. Exceptions or warnings generated from other functions shall be sent to this professional (and others indicated); e.g., warnings regarding an increase in risk or the occurrence of a relapse indicator. The service shall enable the acknowledgement of the absence of a care co-ordinator or residential medical officer (e.g., when they are on leave or away sick), and then automatically send the prompts or warnings to an appointed person for action. An appointed person may be indicated to take care co-ordinator or residential
Required Response
Each bidder shall describe how this requirement will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
105.15.2
105.15.3
105.16
105.16.1
105.16.2
105.16.3
105.16.4
FINAL 1.0a
Page 86 of 607
ICRS
Requirement medical officer responsibility on a shortterm basis. Support for this function shall include automatic predetermination of the appointed person, or provide for a manager or other appropriate person to allocate responsibility. It shall be down to choice and configuration at the Cluster level as to how this is implemented. 105.17 105.17.1 Further Requirements During the planning of care, the service shall enable responsibility to be assigned for the plan, pathway or programme to a care team that is either already in existence, assembled from several existing teams or newly created. The service shall enable actions within the planning function to be assignable to roles that are defined within the responsible care team, or individuals. The team roles with which the planning function will interact shall not be limited to Clinicians, but include anyone who might carry out an action on a pathway. This could include non-NHS Clinicians, other professionals, patient family members (especially parents) and the patient. It is expected that the management of care teams and the linking of team roles to actual persons will be carried out using non-ICRS teamwork enabling systems. These systems will include functions for dealing with: 105.17.5 shift patterns; absences, planned and otherwise; and joiners and leavers.
Required Response
105.17.2
105.17.3
105.17.4
In the case of NHS employees most of the teamwork enabling functions will be provided through the NHS Electronic Staff Record (ESR) project. Although ESR is outside the scope of ICRS, the service shall: transmit task assignments to ERS; and
FINAL 1.0a
Page 87 of 607
ICRS
Requirement receive confirmation of the assignment.
Required Response
105.17.6
The service shall enable actions to be re-assigned to team roles at any point while a plan, pathway or programme is running. The escalation of uncompleted tasks to other team members shall be handled by the teamwork enabling systems. However the systems shall be able to mandate escalation in the teamwork systems according to the defined escalation rules. It shall also be possible to launch nested plans from within a broader care programme or care pathway. With regard to CPA for example the constituent elements of a programmed approach to care will incorporate a Care Programme, contingency and crisis plans, mental health and physical health care plans, all of which with be provided for and signed-up to by patients. Tasks on care pathways that have any degree of complexity (i.e. require any information to be recorded beyond noting the completion of a task) shall guide users to the relevant functional component (e.g. assessments, electronic prescribing, scheduling, clinical noting). These components will normally, but not necessarily, be other ICRS components. Upon launch from a plan or pathway, the newly opened ICRS component shall be made aware of the launch context, and present the user view accordingly. The launch context consists of: user identification; patient identification; and identity of the care instance.
105.17.7
105.17.8
105.17.9
105.17.10
pathway
105.17.11
All transactions created through ICRS components launched from the planning function should include reference to the running plan/pathway. This is to enable
FINAL 1.0a
Page 88 of 607
ICRS
Requirement general reporting on the basis of a plan, pathway or programme. 105.17.12 Any ICRS function which is launched from within a care plan/pathway shall, on closure, indicate its exit status, which should be interpreted as the successful completion (or otherwise) of the task for which the function was launched. The business logic at the core of the planning function shall be accessible by other non-ICRS components e.g. myhealthspace. As well as ICRS, it shall be possible to launch non-ICRS functions from a care plan/pathway. These may be linked to: 105.17.15 a pathway task (e.g. a relevant location in a web-based guideline document); the pathway as a whole (e.g. a link to an evidential source); and the team (e.g. update a roster).
Required Response
105.17.13
105.17.14
The service shall allow for appropriate context and exit status handling between ICRS components and between ICRS and legacy systems. Care plans, pathways and programmes will form the default unit of confidentiality. The service shall enable permissions to view data stored within the service for the responsible care team to be set. Changes to the default confidentiality profile of a pathway shall be expressed as variances from that default. Consent shall be incorporated within the care plan/programme (see module 730 in OBS Part III). Each bidder should suggest ways in which the signing of consents can be securely managed in a manner that does not require the storage of paper.
105.17.16
105.17.17
105.17.18
105.17.19
There shall be provision for the operation of the planning function across the Cluster boundary, both with other ICRS Clusters and with non-ICRS communities (e.g. Wales, Scotland,
FINAL 1.0a
Page 89 of 607
ICRS
Requirement non-UK, private sector). 105.17.20 It shall be possible to assign research status to a care plan/programme. It shall be possible to link a research plan/programme/pathway to a specific project or trial which itself will be linked to specific care teams and patients. It shall be possible to set up research pathways as shadows of operational care pathways. When users use expert systems to guide them to a care pathway, they will be guided to a research care pathway instead of the standard operational one, if the care team and patient context is appropriate. The service shall have the ability to set up flexible workflow to support the process of referral, assessment, care plan, review and closure (with the middle three elements of the process recurring in some instances), including: the ability to track timescales between the elements, and the ability to show items by the next process due, and how long it has been waiting; the ability to set default standard and maximum dates for elements of this processing (which may vary by care community/ local authority boundary). Note that within this workflow, there may be other assessments commissioned and recorded; and the ability to distinguish these (more specific assessments) and the workflow around them, within the context of the major process.
Required Response
105.17.21
105.17.22
105.17.23
105.17.24
Research care plans/programmes shall be time-limited by start and end date, and it shall not be possible to start a care plan/programme outside that range.
FINAL 1.0a
Page 90 of 607
ICRS
Requirement 105.17.25 The service shall provide the ability to incorporate different data formats for care plans/programmes which straddle health and social care chiefly with regard to the inclusion of documents either as structured forms or scanned documents. The service shall provide the ability to structure a care plan mixing internally and externally provided services, (i.e. services outside of the healthcare service) detailing the quantity, times and regularity of services (including start and proposed end dates). The service shall provide the ability to communicate individual elements of the care plan to the different suppliers of service, and provide all other appropriate information at the same time (dependent on the type of service). The service shall have the ability to identify elements of the care plan that are social care, and export these to external systems in a standard format across defined interfaces or messages. The participation of patients in the process of planning their care is critical, including asking for their explicit permission to share information and their consent to assessment and treatment.
Required Response
105.17.26
105.17.27
Each bidder is asked to describe how this would be achieved.
105.17.28
105.17.29
Each bidder is asked to describe how patient involvement in the planning of care is incorporated within the solution.
FINAL 1.0a
Page 91 of 607
ICRS
106 - Clinical Documentation, including Clinical Noting and Clinical Correspondence Overview This module specifies the requirements for the service to enable and facilitate the: structured recording of clinical notes for medical history and treatment; completion of clinical summaries, including discharge summaries; generation and sharing of patient-based clinical letter communications; storage, management and retrieval of patient-based clinical letter communications; integration of patient-based clinical letter communications with the patients Patient Record; and electronic sharing of clinical letter communications across a patients healthcare team. This assumes that, in the long term, such information will be automatically generated and electronically transmitted.
The purpose of this module is to provide functionality which will support the recording of structured and, where necessary, unstructured clinical notes, summaries and letters. The LSP Services will be an enabling solution in moving from what is largely a paper-based process of noting and clinical correspondence to a more streamlined electronic process. The LSP Services will provide the ability to record contemporaneous notes as part of the care process and will derive information from within the Patient Record to populate clinical summaries, including discharge summaries. Moreover, access to the LPS Services directly by all care professionals across all care settings will negate the need to provide additional correspondence which is currently required to facilitate the handover of care. It is recognised, however, that the process of moving towards replacing paper-based clinical correspondence with electronic clinical communications may take some time to achieve. In the meantime, it is intended that this module will provide support in producing clinical summaries and other correspondence in areas where progress towards automatically-generated electronic clinical communications is expected to be slow or will require significant process re-design. The functionality that the LSP will provide will offer interim benefits for users and patients in their current paper-based communications. The functionality provided shall allow for integration with future and/or current electronic clinical communications functionality. (See Module 770 - Clinical Communications). Scope Components Key elements of clinical documentation covered by these requirements include: clinical notes, including, but not limited to: operation notes; medical history, where this is not part of a structured assessment; treatment notes; and documented observations; referral letters; out-patient clinic letters; alerts from systems in one sector to another that a patient is undertaking an Episode of care (e.g., GP system alerted to patients admission to A&E); immediate discharge summaries, including ToTakeAways (TTA); final discharge summaries; and copies of the above to patients, either in electronic or printed format.
This information will be provided through LSP Services into the Patient Record and will be available through the Spine. The mechanism for transfer between the LSP Services and the Spine is described in the following modules: Module 770 Clinical Communications;
FINAL 1.0a
Page 92 of 607
ICRS
Module 780 Interfaces; and Module 200 Personal Spine Information Services.
Exclusions The Phase 1 requirements are not intended to address significant workflow or changed processes. These may well be required at the Cluster level and will be required in Phase 2. Copy letters to patients are excluded in the initial stages, but will be implemented later in accordance with NHS Plan targets. Benefits and Outcomes Current Situation Some of the current problems which LSPs will need to resolve include: lack of an effective clinical noting solution which supports the requirements of Clinicians at the point of care; letters lost or delayed in the post or internal mail (typically, several days elapse before these are received by the patients GP or other community-based healthcare staff); inefficient processes, reliant on medical secretaries with limited capacity; information is not accessible in a timely manner to all who need to know it, which introduces a risk of drug-related errors; no easy retrieval or reproduction of clinical letters; no efficient storage of patient letters; no linkage of clinical information to the patient's record; clinical correspondence (including discharge summaries) is not automatically produced in the majority of hospitals; most discharge summaries are in printed format and disseminated via the postal service or internal mail. Typically, several days elapse before these are received by the patients GP or other community-based healthcare staff; where discharge summaries are automatically produced, there is no standard definition of the discharge summary or its contents; clinical correspondence (including discharge summaries) tends not to be coded, which makes assimilation into the patients Patient Record and subsequent analysis problematic; and patients do not necessarily receive a copy of relevant clinical correspondence (including discharge summaries).
Desired Benefits and Outcomes To: Patient More timely and reliable communications. Easy and timely access to their own healthcare information. Clinician Enables a consistent, structured approach to clinical notation/documentation for each discipline. Enables clinical notes to be shared across all care settings. Reduces duplication of work and information. Availability of clearer, high-value information for continuity of care in the community/home postdischarge (which permits care workers to know recommended regimens for post-acute care, including Take Home Prescriptions, reducing the risk of drug-related errors).
FINAL 1.0a
Page 93 of 607
ICRS
Improved prescribing practices, particularly within hospitals, and reduced risk of drug-related errors. Crucial element of the patients record available on-line for viewing. Capture of clinical terminology and codes to improve quality and aid subsequent analysis. More timely and reliable communications which are easier to store and retrieve. Manager
Move towards paperless environment. Less storage and transport of notes. Better information security (allows secure back-up and retrieval). Capture of clinical terminology and codes to improve quality and aid subsequent analysis. Improved prescribing practices, particularly within hospitals. Improved productivity of medical secretaries and other staff currently producing letters.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Support for the generation and sharing of key items of correspondence, linked to individual Patient Records. For Phase 1, these could be transferred by email or structured Messages and would include, as a minimum, consultant letters. Minimum Level to Be Achieved by December 2006 (Phase 2) Phase 2 would provide an expansion of scope in terms of the range of clinical noting and correspondence included (e.g., referral letters and discharge summaries), as well as the extent to which these are generated as a direct result of clinical processes. There should be a facility to integrate correspondence between legacy and new systems across all sectors. Target for 2010 Generation of all correspondence as an automatic by-product of clinical processes, supporting data collection. Ability to record clinical notes in real time at the point of care. LSPs are invited to state any ability to deliver in excess of these minima within the timescales stated. Overview Requirements Requirement 106.1 Overview The functionality to be provided in Phase 1 will require Cluster-level efforts to upgrade current arrangements, which are often based around discrete word processing systems or Clinical Audit databases. The automated generation of clinical correspondence required in Phase 2 (including discharge summaries) implies Required Response Each bidder shall describe its approach to delivering this module.
FINAL 1.0a
Page 94 of 607
ICRS
significant changes to current working practices and potential training needs. There will need to be Cluster-level agreements on changing the process of letter communications, which will need to be supported by the LSP. 106.2 Benefits and Outcomes The expected benefits and outcomes have been set out above. 106.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. Each bidder shall describe how it would deliver the benefits and outcomes from this module.
106.4
Detailed Requirements Requirement 106.5 Clinical Noting Required Response Each bidder shall describe how each of these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches. Each bidder shall describe how structured and unstructured clinical notes are incorporated within the solution.
106.5.1
Clinical noting will need to support both structured (e.g., operation notes for a specific surgical procedure) and unstructured notes (e.g., by providing the ability to record notes of a telephone conversation, and to store freehand drawings, annotated diagrams and digital images see 115). Structured notes will require the use of template formats, which can be locally tailored for specific types of clinical notes.
106.5.2
Each bidder shall describe how the formats for structured notes can be set up and tailored locally.
106.5.3
Clinical notes shall be attributable to the author. Nothing may ever be removed from the notes and any changes to the
Each bidder shall describe how clinical notes are "signed-off" and how changes are authorised and audited.
FINAL 1.0a
Page 95 of 607
ICRS
Requirement notes shall be audited. 106.5.4 Standard clinical coding and terms shall be applied at specific, locally-defined points, where relevant. Clinical notation shall incorporate different formats and media, including body maps, drawings, and graphical, textual and numerical information, as well as audio and video records. Clinical noting may require supporting technology to translate a Clinicians notes into an electronic format (e.g. from tablet P.C.s, audio equipment or where Clinician has used drawings/diagrams etc.). Generation of Clinical Correspondence
Required Response
Each bidder shall describe how clinical coding and terming is incorporated or derived from recording of clinical notes.
106.5.5
Each bidder shall describe how their services will support and integrate with such technologies.
106.6
Each bidder shall describe how each of these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
106.6.1
The service shall support the production of a range of documentation; e.g.: discharge summaries (immediate and final); out-patient clinic letters; and referral letters.
106.6.2
The service shall support the delivery of documents such as, but not limited to: paper; email; and structured Messages (e.g., HL7 V3).
106.6.3
The service shall enable the creation of letters from standard templates to which particular comments can be added. The service shall pre-populate the templates (e.g., use rule-based intelligence to select which address is appropriate from the information stored in the patient's Patient Record or the PDS). Any amendments, corrections and/or changes shall have Audit Trails; and, once sent out, documentation shall be
106.6.4
106.6.5
FINAL 1.0a
Page 96 of 607
ICRS
Requirement made read-only. 106.6.6 The service shall support enlarging of print for patients with visual impairments and also translation into Braille, or, recording onto audio tape. It would be desirable that any patient information leaflets (e.g. Rights Under the Mental Health Act) or conditionspecific information be printed in a language other than English, if such preference is indicated at the point of registration. The service shall support user-selected batching and printing of letters; e.g.: by priority; by GP; by practice; by document type; and by postcode, (to fit with Post Office discounts).
Required Response
106.6.7
106.6.8
106.6.9
The systems shall support printing of associated documents; e.g., check lists, maps, leaflets, instructions, appointment cards, etc. The service shall support the storage of clinical correspondence, including discharge summaries. All documents generated shall be stored against the patient's Patient Record. The service shall enable viewing of clinical correspondence. Access to documents shall be controlled by role-based access and limited to authenticated users. All user access shall be recorded and have Audit Trails. Configuration management shall apply to the documents. Changes, amendments, corrections and deletions shall be recorded in the Audit Trails. The service shall support integrated, specialist, multi-disciplinary (including Social Care and mental health) team
106.6.10
106.6.11
106.6.12
106.6.13
106.6.14
FINAL 1.0a
Page 97 of 607
ICRS
Requirement records with ICPs shared across teams, disciplines and organisations. 106.6.15 The service shall support locallydefined, role-based "vi ews" of patient data. The service shall be able to receive a nationally-defined discharge notification, and other nationally-defined Messages. The service shall be capable of producing and exporting Patient Record summaries with nationally-defined content and formatting, including SAP and CPA information. The service shall enable pointers to be held within the Patient Record giving access to: (a) correspondence sent or received in respect of the patient; and (b) any other relevant documents originating from outside the system. This shall include the ability to store or link to scanned documents, where appropriate. The service shall enable templates for standard and non-standard letters to be set up and accessed, drawing on data from the system for pre-formatting and entry of existing field contents but allowing additional free text. Where appropriate, nationally-defined templates shall be used. It shall be possible to electronically mail these documents, where appropriate. The service shall enable appropriate copies of summary reports to be sent to any GP, care coordinator, Social Services or independent care provider, as appropriate. The service shall provide the ability to record contemporaneous notes as part of the care process. This includes operation notes for surgical procedures, medical notes with are supplementary to assessments, medical history, treatment notes, community and social
Required Response
106.6.16
106.6.17
106.6.18
106.6.19
Each bidder shall describe how its solution accommodates the requirement for local set up and management of clinical correspondence templates.
106.6.20
106.6.21
106.6.22
FINAL 1.0a
Page 98 of 607
ICRS
Requirement care notes and such like. 106.6.23 The service shall enable the creation of referral communications which should incorporate links with referral protocols and guidance. The referral letter shall be linked to the electronic booking process. The service shall enable draft notes to be created and edited prior to committing the note to the record. Once a note has been committed to the record it can only be altered through audited change control (as per 106.6.5). Correction or updates shall only be recorded as supplementary to the original notes. The service shall enable clinical notes and documentation to be accessible through different views according to the users requirement, this will include as examples: chronological view of patient notes within or across care events; by care profession; and as part of another function, e.g. as part of a care pathway.
Required Response
Each bidder shall define how the solution supports an effective operational process which links referral communication, referral protocols and electronic booking.
106.6.24
Each bidder shall define how draft notes are managed, particularly with regard to notes which remain in draft form for a defined length of time.
106.6.25
FINAL 1.0a
Page 99 of 607
ICRS
107 - Care management Overview This module specifies the requirements for the management of specific types of care event, independent of care setting. Only a modernised approach to managing demand and capacity will deliver this functionality successfully. To understand more about this approach see http://www.modern.nhs.uk/rowbi. Requirements are provided for unscheduled care management, domiciliary care management, ambulatory care management, bed management and demand or access management. With the shift from acute-based care to community and primary -based care, the traditional approach to provision of out-patient and in-patient management wholly within a hospital environment is no longer valid. This section therefore describes the management of care within the settings of: Unscheduled Care, which is concerned with care which takes place in any healthcare setting, the timing and scope of which has not been pre-arranged. Detailed requirements for such care are listed in Section 122. Domiciliary-based care, which is concerned with care which takes place in a patients home and which incorporates a significant proportion of community care activity, such as district nursing and specialist nursing. Ambulatory care, which is concerned with care that takes place in a healthcare facility for patients who do not require the use of a bed. This will include walk-in centres, diagnostic and treatment centres, hospitals and GP surgeries. Domiciliary care and ambulatory care requirements will largely be supported through the application of generic functions, such as assessment, clinical documentation, ordering and care planning/care pathways. However, specific functionality around the attendance of patients and the logging of visits for ambulatory care and domiciliary care, respectively, will be incorporated within the requirements of this module. Bed Management is concerned with the management of in-patient, and possibly day case, facilities, where there is a requirement for the admission of a patient to a bed. This may be a facility provided by a DTC and will not necessarily be a hospital. Bed management will link closely with scheduling and may be an integral component of some scheduling solutions. Demand/Access Management is concerned with the management of patients who are waiting for treatment, either with or without a confirmed booking date. The requirement that PCTs manage the demand for elective services will require a cross-organisational approach to access management; which will embrace informed patient choice, and which will require the support of effective information systems to measure and present access times for packages of care at the point of referral. Dental Chair Management is concerned with the management of dental chair facilities, where there is a requirement for a patient to undergo dental care. This may be a facility provided by a hospital or community facility. Dental chair management will link closely with scheduling and may be an integral component of some scheduling solutions.
Unscheduled care management Purpose To enable the management and recording of unscheduled care provided in any setting; including, but not limited to, a patients home, A&E, out of hours, primary care facilities (including GMP and GDP practices), ambulances (paramedics may be able to treat some patients themselves instead of taking them somewhere to be treated), walk-in centres, minor injury units or via NHS Direct.
FINAL 1.0a
Page 100 of 607
ICRS
Incorporating attendance management, waiting time recording, and clinical intervention. In respect of patients for whom a decision is made to admit to a hospital bed, to incorporate the identification and allocation of beds that are available for use, bed occupancy and the corresponding demand (see 108 - Scheduling).
User Population Clinical and non-clinical staff that are required to deliver or administer unscheduled care.
Care Setting Hospital and clinic based care. Care provided through NHS Direct, in the patient's home, GMP and GDP Practices or in other care settings where unscheduled care is provided.
Patient/Client Access Patient access is not required directly, however information on waiting times, number of users, and other data required centrally about these services shall be made available to central information sources e.g. StHAs and DH. Systems Integration. Must share the ePDS. Shall integrate with Scheduling and eBooking. Shall be integrated with all clinical components such as Assessment and Clinical Noting to ensure clinical activity is linked to the visit/ attendance. Shall integrate with results reporting. Data systems shall be able to provide, at a minimum, current central data requirements and centrally recommended minimum data sets. Shall integrate with NHS Direct and ambulance call centre systems as well as primary and secondary care outpatient booking systems. Shall be able to link social worker details and care plans for patients in contact with Social Services.
Benefits Enables more effective management of unscheduled care. May contribute to reducing waiting times in A&E and elsewhere as patient flows through the hospital can be managed more effectively. Supports timely discharge from A&E. Knowledge of a patients background and records will enable more timely, appropriate and effective treatment interventions as patient background and record is known.
Composition Identification of resources/facilities which can meet patient need as part of delivering unscheduled care. Administration of unscheduled cases. Identification of available beds once a decision to admit has been made. Booking of patient into facility once a decision to admit has been made, possibly through scheduling/ ebooking or through another route. Results reporting. Recording and management of attendances and clinical activities including waiting times and patient tracking.
Exclusions Scheduled care.
FINAL 1.0a
Page 101 of 607
ICRS
Functionality Patient tracking and location. Management of attendances, including waiting times. Shall link to ambulatory care management and bed management systems. Link with assessment and clinical noting components to link attendance record with clinical record. Admission, transfer and discharge of patients. Link with social care support systems to access combined care plans and provision of joint social/health care services on discharge.
NHS Direct and/or out of hours could be separate and/or part of the ambulance call-centre system with an interface to unscheduled care functionally the physical location of these three components may vary and either the NHS Direct or the out of hours option must be possible Domiciliary Care Management Purpose To enable the management and recording of care provided in the patients home or residence by Clinicians.
User Population Clinical and non-clinical staff that are required to deliver or administer domiciliary care.
Care Setting Home-based care provided by any health or social care professional.
Patient/Client Access Patient access may be required to enable services which are delivered in the patients home to be requested.
Benefits Enables more effective management of domiciliary-based care with more effective scheduling of home visits and co-ordination between community-based health or social care professionals and between community-based health and social care professionals and Acute Care. Supports the effective delivery of home-based care to increase patient independence. Effective home-based care reduces admission to hospital and supports early discharge.
Composition Identification of resources and facilities which can meet patient needs as part of planning homebased care. Scheduling of resources, including human resources and equipment to support patients in their own homes. Recording and management of visits and clinical activities for home-based care.
FINAL 1.0a
Page 102 of 607
ICRS
Exclusions Nursing and residential home care.
Ambulatory Care Management Purpose To enable the management of ambulatory care patients in any care setting, including out-patient clinics, DTCs, ward attenders, walk-in clinics, etc., including in relation to bookings (if not incorporated within scheduling), attendance management, waiting times and clinical interventions. Attendance management is described in the Revision of Waiting and Booking Information model (see RoWBI website: http://www.modern.nhs.uk/rowbi).
User Population Clinical and non-clinical staff that are involved in the care of ambulatory patients.
Care Setting All care settings where patients attend for assessment or treatment and do not require the use of a bed.
Patient/Client Access Patient access is not required.
Systems Integration Shall integrate with Scheduling and eBooking with regard to appointment and rebooking information. Shall be integrated with Demand/Access Management. Shall be integrated with all clinical components of the LSP Services such as assessment and clinical noting to ensure clinical activity is linked to the attendance.
Benefits Enables more effective management of non-in-patient care and increased choice for the patient in allocating a resource based on patient need rather than administrative arrangements. Will substantially contribute to reducing waiting times as capacity in all care settings can be made available. Will enable care to be provided more locally for the patient
Composition Identification of resources/facilities which can meet patient need at point of referral/booking. Booking of patient into facility, possibly through Scheduling/eBooking or through an interface between a booking system within ambulatory care and Scheduling/eBooking. Recording and management of attendances including clinic management, waiting times, patient tracking.
FINAL 1.0a
Page 103 of 607
ICRS
Variants Booking of ambulatory care patients could be part of ambulatory care management with an interface to scheduling, or could sit within scheduling with attendance management only within ambulatory care.
Bed Management Purpose To enable the management of bed resources, incorporating the identification and allocation of beds which are available for use, bed occupancy and corresponding demandfor beds. To identify the allocation type of a bed (e.g. critical care). This is vital for appropriate management. The Service should be capable of estimating demand for elective beds. Demand for elective beds should be/can be derived from estimated length of stay for each patient on a schedule or waiting list.
User Population Clinical and non-clinical staff that are required to allocate/manage beds. Care setting. Hospital-based care, community and intermediate care facilities and any other facilities which use a bed e.g., DTCs.
Systems Integration Shall be integrated with Demand/Access Management. Shall be integrated with all LSP clinical components, such as assessment and clinical noting, to ensure clinical activity is linked to the admission.
Benefits Reduces administrative effort in identifying and allocating beds.
Composition Administration of in-patients and day cases. Identification of available beds. Identification of demand for beds at a point in time, based on patients booked to come in and patients planned for discharge.
Variants Bed management may be a function incorporated within scheduling.
Demand/Access Management
FINAL 1.0a
Page 104 of 607
ICRS
Purpose To enable the management of patients who require treatment which is delayed in time from the decision to treat, as described in the Revision of Waiting and Booking Information model (see RoWBI website: http://www.modern.nhs.uk/rowbi). This applies to both in-patients and ambulatory care patients. PCTs are responsible for management of waiting times; therefore, this component must be available to both Primary Care and Secondary Care.
User Population Clinical and non-clinical staff that are required to administer patients who are booked for a service and PCT/secondary staff responsible for managing access times.
Care Setting All care settings where patients are required to be booked for a service.
Patient/Client Access Patient access is not required directly, however the information on access times must be made available to public information sources, e.g., Web sites. Systems integration. Must integrate with scheduling with regard to waiting times to be seen.
Benefits Enables cross-organisational management of access times. Enables management of total access times for specific treatment and care where different services are involved. Enables a referrer to select services based on the best access time. Reduced effort in producing waiting time statistics, as they will be automatically derived from booking/scheduling and will be shared across the health community. Benefit will be realised when underlying systems routinely capture demand and capacity data.
Composition Data recorded as a by-product of booking/scheduling activity is used to report total demand for services in terms of waiting time.
Exclusions Booking and scheduling of patients.
Dependencies Effective management of bookings across the health community. Real time-derived information of booking/scheduling activity.
Dental Chair Management Purpose To enable the management of dental chair resources, incorporating the identification and allocation of chairs which are available for use.
FINAL 1.0a
Page 105 of 607
ICRS
User Population Clinical and non-clinical staff that are required to allocate/manage chairs. Hospital and community based and other facilities which use dental chairs.
Systems Integration Shall be integrated with Demand/Access Management. Shall be integrated with all LSP clinical components, such as assessment and clinical noting, to ensure clinical activity is linked to the chair usage.
Benefits Reduces administrative effort in identifying and allocating chairs.
Composition Administration of dental activity. Identification of available chairs. Identification of demand for chairs at a point in time, based on patients booked for dental care.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) All sites must have had these requirements implemented by the LSP by the end of Phase I. Target for 2010 Over the lifetime of the project, it is expected that the reliance on organisation-specific requirements will be replaced by a series of generic functions and a community-wide record. Bidders are invited to state any ability to deliver in excess of this minimum within the time frames stated. Overview Requirements
Requirement 107.1 Overview The service shall incorporate all care settings and disciplines including but not limited to consultant led hospital based facilities and the community provision of beds managed by GPs or other community staff. Bed management may not be part of scheduling; but it shall be integrated with it, as a minimum, to enable beds to be scheduled as part of
Required Response
Each bidder shall describe its approach to delivering the requirements for acute care.
FINAL 1.0a
Page 106 of 607
ICRS
Requirement the care pathway along with other associated resources, such as theatres. Attendance management, waiting time recording and clinical intervention applies to patients receiving care in primary, community based and other care settings as well as acute care settings. 107.1.1 The service shall be able to identify any other on-going episodes of care or treatment for any reason in any care setting. It should prompt notification of other services where an admission to inpatient care has taken place. Benefits and Outcomes The implementation of acute functionality is often a critical first step to the implementation of care records. 107.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP.
Required Response
107.2
Each bidder shall d escribe the benefits it could expect to see from acute functions, and describe how it would provide quick win benefits in parallel with the wider project requirements. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
107.4
107.5 107.5.1
Domiciliary Care Management The service shall provide access to Patient Records, including referral details, care already delivered (including care received from other professional groups), and current and previous treatment/care plans. The service shall be able to record all details of the care delivered, including: all staff involved; date/time and type of intervention; duration; non-attendance for treatment; all services ordered for the patient (or carer); and also consumables and prescriptions. The service shall be able to interface with home monitoring equipment, such as physiological and Each bidder shall describe how it will address these requirements.
107.5.2
Each bidder shall describe how it will address these requirements.
FINAL 1.0a
Page 107 of 607
ICRS
Requirement environmental sensors, and support monitoring of daily living functions. 107.5.3 This service will be integrated with all clinical components, such as assessment, clinical noting, domiciliary care management, bed management and demand/access/demand management to ensure clinical activity is linked to visits. This service will be an integrated component of ICPs to plan, schedule and deliver home-based care. The service functionality will include: scheduling of all home-based visits by care professionals, including district nurses, specialist nurses, Health Visitors, voluntary services, care assistants, etc; recording of all activities undertaken during a visit; e.g., support for activities of daily living; support concurrent episodes to be linked for all care provided across care settings and schedule resources and visits accordingly; link with Social Care support systems to support combined care plans and provision of joint social and health care services; and link with home-based patient monitoring, such as community alarms and environmental sensors, to support patients at risk.
Required Response
107.5.4
107.5.5
107.5.6
The service shall enable dependencies between Episodes to be created and resources and visits scheduled accordingly. The service shall support links to associated support and delivery services ie continence products. The service shall support management processes associated with staff based at and working from remote locations. This shall include the ability to: send and retrieve messages to and from the base and handheld devices
107.5.7
107.5.8
FINAL 1.0a
Page 108 of 607
ICRS
Requirement either automatically to notify of an admission or on an a d-hoc basis to notify of additional visits; and access to staff diaries from administrative locations
Required Response
107.5.9
The service shall enable any special rules or instructions with regard to access to residences to be recorded, particularly for patients with limited mobility. Ambulatory Care Management The service shall provide the ability to set up, manage and operate clinics and sub-clinics, while meeting central statistical requirements. Clinics will include, but are not limited to:: GP attendances; consultants; sub-clinics including registrars; joint consultants clinics; minor operations clinics; nursing; therapies; midwifery; diagnostic; multi-disciplinary; diaried visits for mobile staff in any home or community setting; outreach clinics; school visits; telemedicine clinics; and specialist GP clinics. The service functionality shall support effective demand and capacity management and will include: booking and scheduling of all ambulatory care arrangements including booked clinics, walk-in clinics, ward attendances etc; patient tracking and location; management of attendances in clinic, including waiting times; link with assessment and clinical noting components to link attendance record to clinical record of ambulatory care; link to Demand/Access Management; Each bidder shall describe how it will address these requirements.
107.6 107.6.1
107.6.2
FINAL 1.0a
Page 109 of 607
ICRS
Requirement the facility to re-schedule and rename clinics even where appointments have been booked. This should automatically generate letters to inform the patient; the facility to link appointments where more than one is made on the same day e.g.) for a consultant and for the fracture clinic; assumptions; e.g., the assumption that day care patients attending for invasive treatment will be part of bed management, however assuming that day care beds can be managed independently of in-patient beds, this facility could be used to manage day care. Bed Management
Required Response
107.7 107.7.1
The service shall provide the facility to record, review and revise data for patients admitted as elective and nonelective in-patients, as well as day case investigations and treatment. This encompasses: in-patient appointments diary; Enterprise Wide scheduling; admission; transfers; discharges; clinical coding; bed management; ward attenders; consultant transfer; home leave; regular day and regular attenders; and special considerations for dialysis patients.
night renal
107.7.2
The service functionality will include: admission, transfer and discharge of in-patients and day cases from facilities which use beds; in-patient tracking and location; views of bed availability and occupancy within and across organisations by specific criteria; e.g., specialty, age/sex mix, etc.; and planned and pending discharge management which identifies
FINAL 1.0a
Page 110 of 607
ICRS
Requirement delayed discharges. 107.7.3 The facility to record, manage, print or provide an electronic copy of, a real-time bed status which shows beds occupied, beds booked and empty beds. The facility will include the ability to: identify beds uniquely (e.g. by numbering or lettering or combination of both); identify beds as closed; identify beds as empty; Identify beds as male or female beds; identify beds as allocated to a consultant/speciality; place a holding status on a bed for: e.g. patients on home leave; and patients due to come in to the bed (from any source); and change bed status subject to user rights.
Required Response
107.7.4
There shall be the facility to record and report upon 'Delayed Discharges', where patients with finished Episodes are occupying a bed awaiting discharge. The facility shall include: original intended discharge date; anticipated discharge date; reason for delay; and Care professional responsible for facilitating the discharge.
This shall be linked to the careplan which identifies actions being taken to enable discharge to take place. 107.7.5 The service shall provide the ability to automatically initiate closure of all outstanding activities and cancellation of all future events when a patient death is recorded, other than those which are a consequence of the death. The system shall allow for transfer of patients/information e.g. between wards and Trust sites, care providers, care settings, administrative category, legal Each bidder shall describe the safeguards that would be applied to this function.
107.7.6
FINAL 1.0a
Page 111 of 607
ICRS
Requirement status, consultant and speciality. 107.7.7 The system shall provide the option of booking an out-patient appointment in a range of settings other than where care has been delivered as part of the discharge function. The service shall provide the ability to activate pre-arranged services from other care providers e.g., District Nurses, Community Midwives, and Social Services. Demand/Access Management The service shall provide the ability to capture demand and set up waiting lists to support in-patient and therapeutic care and the delivery of all other ambulatory and non-ambulatory care. The service shall provide the ability to validate and review in-patient waiting lists. The service shall be part of the fully integrated scheduling system to link with: pre-admission functionality; bed management; rostering; capacity monitoring and planning; hospital sterile supplies department sterile supplies; anaesthetic functionality; perioperative (theatres, etc.); and transport; and notification to patients of changes in appointments (see Section 106).
Required Response
107.7.8
107.8 107.8.1
Each bidder shall describe how it will address the requirements relating to different types of service.
107.8.2
107.8.3
107.8.4
The waiting list service shall provide the following functionality: add to list; remove from list; transfer between lists; cancel patient and hospital; (must be able to separately add to and remove from list); refuse; suspend;
FINAL 1.0a
Page 112 of 607
ICRS
Requirement re-instate; and generate an alert if local or national maximum waiting times are being approached or are exceeded.
Required Response
107.8.5
The service functionality shall include: booking and scheduling of all nonemergency intervention to be fed to demand management to support reporting of access times and demand metrics across the health community; and calculation of total access time according to care pathway/diagnosis/condition.
107.9 107.9.1
Dental Chair Management The service shall monitor and analyse dental chair usage by keeping detailed records which will be shown in a chair management report. Each chair must belong to a chair group and a default chair must be recorded against each clinic session. Service to support daily calculations of chair usage from clinic activity for that day and previous days, taking into account chair unservicability. . The service shall allow automatic adjustment of the usage of the clinics default chair depending on a patients attendance or non-attendance. The user must be allowed to assign an alternative chair provided it belongs to the same group. There must be more than one chair group associated with a clinic group, but the chair group may only have one profile. The service shall support this. The time that a chair is available for use must be expressed as hours and minutes for each day although this may not necessarily be the same as the length of a clinic session. The service shall support this. Each bidder shall describe how it will address these requirements.
107.9.2
107.9.3
107.9.4
107.9.5
FINAL 1.0a
Page 113 of 607
ICRS
Requirement 107.9.6 The service shall record chair unserviceability and the reasons for such status. Unserviceable status may be recorded for a range of dates or for one single date. Serviceability must be toggled on and off for specified dates. The service shall update chair usage history on a daily basis by monitoring attendance records. When a patients attendance is recorded the default chair is assumed to have been occupied (although there must be some allowance to change this by selecting to amend the patients attendance details). The service shall report chair status on the basis of the following: 107.9.9 chairs that have been used and booked. chairs that have been used but not booked. chairs that have not been used but have been booked with DNA recorded. chairs that have not been used due to unserviceability. chairs that have not been used or are spare.
Required Response Each bidder shall describe how it will address these requirements.
107.9.7
107.9.8
The service shall support individual chair allocation by patient or clinician.
FINAL 1.0a
Page 114 of 607
ICRS
108 - Scheduling Overview This module specifies the requirements for the service, within the LSP Services, relating to scheduling. See also Module 105 Integrated Care Pathways and Care Planning (including ICPs and CPAs), which is closely related. Scheduling will often involve the scheduling of resources from more than one organisation, across a range of care delivery environments. Effective scheduling will also require the adequate capture of demand data and prediction of future capacity use. The scheduling solution proffered must be flexible enough to accommodate existing and emerging working practices, across the whole range of health care delivery environments and locations. Schedule Patient Appointment/Diary Management/Non Clinical Staff Activity The management and scheduling of clinic sessions, appointments and follow-up work arising from appointments should be made easier for staff. This functionality may be required from a number of points within the system. The functionality should include the facility to schedule: an assessment; a patient treatment/intervention; screening/review; updating tests; e.g., neurological; a non-face to face contact e.g., review of patient by telephone; a group session/clinic; a training course attendance; a case conference; and meetings.
The service shall provide a facility to search and match resources using user-definable criteria, e.g., a search for the most appropriate appointment or series of appointments, such as: recurrent appointments over a fixed period (e.g., every Tuesday at 1500 hours for ten weeks); next urgent; next routine; next at a specific location; or next with a specific Clinician. Appointment requests may be generated by a number of functions, such as referral or assessment, or due to other contacts with the patient or other professionals/services. Appointments may be scheduled from any location to be held at any location e.g., the patients home, DTC, GP surgery, health centre, mental health resource centre, community hospital, clinics, etc. Scope Components The scheduling functionality must provide a process in which events that need to occur in order to deliver patient care are assigned a date, time and place in the future when the resources that are required to carry out those events are available. It is to be available at three levels: departmental scheduling (intra-departmental); enterprise-wide scheduling (inter-departmental and intra-organisational); and scheduling across a healthcare community (inter-organisational).
FINAL 1.0a
Page 115 of 607
ICRS
Exclusions This module does not address ordering functionality (see Module 110 Requesting and Order Communications) which would need to interface with carrying out specified activity.
Benefits and Outcomes Current Situation The adoption of electronic scheduling systems has not been widespread, so that many organisations rely on paper-based systems for scheduling. Where electronic scheduling systems do exist, they tend to work at departmental or personal levels, which can cause difficulties when setting up integrated services across more than one organisation. Desi red Benefits and Outcomes To: Patient Improved organisation and continuity of care. Provision of integrated services from more than one organisation. Clinician More efficient time management. Manager Improved ability to plan and measure the use of personnel and resources. Ability to document by exception.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Cross-organisational scheduling and care pathways are essential to support the service changes envisioned in the NHS Plan and the GMS Contract. This functionality is needed to support the role of GP specialists and intermediate care teams in providing integrated care to patients. Minimum Level to Be Achieved by December 2006 (Phase 2) As for Phase 1, plus any scheduling functionality essential to support the basic component parts of ICPs i.e., the model care pathway, care pathway in use, and the ended care pathway. Target for 2010 Full functionality, as described in all sections of the requirements. Overview Requirements Requirement Required Response
FINAL 1.0a
Page 116 of 607
ICRS
Requirement 108.1 Overview The core requirement is the ability to electronically book (and retain information about) all necessary resources (people, places, equipment, investigations, interventions and events) associated with the diagnosis, treatment and care management of the patient. This will often involve the scheduling of resources from more than one organisation across a range of care delivery environments and identifying demand, both of which are closely linked with the delivery of care plans (see Module 113). 108.2 Benefits and Outcomes The expected benefits and outcomes have been set out above. 108.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP.
Required Response Each bidder shall describe its approach to delivering the required components of ICPs and scheduling linked to the ICRS. Identify any requirements or limitations that might apply to integrating the functionality of ICPs and scheduling solutions with other components of ICRS.
Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 2 functions. Describe what functionality delivered within Phase 1. could be
Each bidder shall describe which additional functions it would be able to deliver by 2010. 108.4 Authoritys Responsibilities Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
Detailed Requirements Requirement 108.5 The service shall enable services to be scheduled (staff, clinics, plus any other special facilities and equipment) at departmental, enterprise and community levels, and encompass investigations, interventions and events associated with the diagnosis, treatment and care management of the patient. Required Response Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
FINAL 1.0a
Page 117 of 607
ICRS
Requirement 108.6 The service shall take account of a range of events and resources needed to deliver care, including: patients; beds and rooms; doctors, nurses, therapists and other care professionals; appointments; admissions; discharges; tests and investigations; operating theatres; equipment; and non-clinical events and resources, such as transport and food.
Required Response Each bidder shall describe how these requirements will be met, noting any limitations, assumptions, dependencies or proposed alternative approaches.
108.7
The service shall provide a management facility to permit multidisciplinary scheduling of staff, clinics and any other special facilities and equipment. The service shall provide a full diary and appointment management service. The service shall enable the restriction of access to diaries and appointment schedules to certain staff and staff groups across the whole range of healthcare delivery environments and locations. The service shall produce appointment notification and cancellation letters to cover fixed appointments, waiting lists, partial and full bookings. The service shall support the user in scheduling a series of resources in the correct order, with fixed or variable time gaps between separate events or tests, according to Trust-specific rules and protocols; e.g. patient attendances that require multiple appointments for tests, such as X-ray, blood, and ultrasound, prior to attendance at a clinic. Such linked or series of appointments may need to be treated together. For example, cancelling an outpatient appointment should cancel the associated ambulance.
108.8
108.9
108.10
108.11
FINAL 1.0a
Page 118 of 607
ICRS
Requirement 108.12 It shall be possible for the result of one step in a schedule of multiple events to cause the next step to be cancelled or to be performed more urgently than the scheduled time; e.g., where an incoming lab result says the next step is not necessary or it shall be done faster. Some events in a sequence may be programmed to start as soon as a previous event has completed with an appropriate result. It shall be possible, at short notice, to re-allocate any item in a booked multiresource allocation and to preserve the order of the other links within the process. When scheduling an event procedure, any conflicts shall flagged clearly (using text graphically) and in real time. or be or
Required Response
108.13
108.14
108.15
As resources are scheduled, the service shall, according to user-defined rules and protocols, prompt the person scheduling to generate associated orders; e.g., requesting of tests or preop clinic slots prior to admission for surgery; where appropriate, triggering of discharge protocols as soon as the patient is admitted; and allowing the generation of appointment, and discharge letters. The service shall allow for the retrospectiv entry of scheduling data. e The service shall support automatic and manual confirmation of scheduling requests, allowing provisional bookings to be made pending confirmation by the servicing department. The service shall provide the facility to schedule and manage "open access" clinics, where no prior booking is required. These will have start and finish times but no individual appointment slots. There shall be a facility to anonymously record a patient attendance; e.g., at a GUM clinic.
108.16
108.17
108.18
FINAL 1.0a
Page 119 of 607
ICRS
Requirement 108.19 The service shall facilitate service cancellation and rescheduling, to accommodate the cases which require schedule priority to be overwritten. It shall also retain all information about cancelled appointments, such information to be made available for management purposes. The service shall allow the alteration of parameters for any resource. It shall be possible to view the diaries for staff that are designated as resources and to enter changes in their availability. The service shall provide a facility to create a holding list of existing appointments if the availability of a resource is changed or to facilitate partial booking. The appointments on the holding list can then be rescheduled when linked resources are re-established or new resources become available. The service shall allow userconfigurable rules to define the extent of resource availability; e.g., to address the need for schedule slots to be restricted to specific resources, to be accessible by specific user groups, or to only be made visible or available within certain time frames. Temporary changes to rules need to be recorded and be made available to enable reporting of true delivered capacity. It shall be possible to define any session by type, location and timeframe, in accordance with individual requirements and working practice. Emergency sessions shall be able to have much wider time variability than normal sessions. The service shall be able to populate a calendar with single sessions or blocks of future sessions. It shall be possible to allocate sessions at varying intervals; for example, daily, weekly, fortnightly and calendar monthly. The service shall provide a facility to search and match resources using
Required Response
108.20
108.21
108.22
108.23
108.24
108.25
FINAL 1.0a
Page 120 of 607
ICRS
Requirement user-definable criteria; e.g., searching for the most appropriate appointment or series of appointments, such as: every Tuesday at 1500 hours for ten weeks; next urgent; next routine; next at a specific location; or next with a specific Clinician. 108.26 The allocation of sessions shall be based on locally-defined rules, which can cope with concepts of specific days in specific weeks in a month as well as the concept of "last" day/week in a month. It shall be possible to allocate (and de-allocate) these automatically in a block. The service shall enable activities and events to be flagged as "do not move" or "do not reschedule." The service shall generate an alert according to Trust-specific, userdefinable rules, to warn the user of any significant eve nts or if any item in the linked resources becomes unavailable; or if a previously required resource becomes available and another patient can be brought forward to take up the resource. The service shall provide immediate notification of any schedule conflicts. When schedule conflicts occur, it shall be possible to configure the system so that it: rejects the request and prompts the user to revise the schedule; notifies the user of the conflict but allows the user to overbook the scheduled service; and allows the user to determine which resources are "blocking" their request. There shall be special warnings when attempting to change or remove a session, person or piece of equipment which already has a diary entry. A list of available alternatives with a similar profile shall be presented. It shall be possible to enable patient choice when multiple events are being scheduled. It shall be easy to report on the notice that had been given for changes.
Required Response
108.27
108.28
108.29
108.30
FINAL 1.0a
Page 121 of 607
ICRS
Requirement 108.31 The service shall provide a facility to alert users, in real time, to current or future events that impact on the resources being scheduled. Further Requirements The service shall support the set-up, definition and amendment of schedules which relate to scheduled resources or facilities. The service shall support the set-up and definition of facilities, resources (including staff) and equipment which can be scheduled. The service shall support the ability to view all scheduled resources from different views including by patient, by resource, by facility and for a defined care plan/pathway. The service shall support the searching, manipulation and allocation of multiple scheduled resources at one time using locally defined criteria. The service shall provide the allocation of available slots which are required by eBooking. This will incorporate the identification of free slots, reservation of slots and confirmation of booking for any facility/resource which can be booked through the electronic booking solution. The service shall support access to the scheduling function as a function in its own right or as part of another function such as a care pathway, a request for a test which requires scheduling of a resource, or part of an assessment process. The service shall incorporate rules based decision support to allocate slots for a facility or a resource based on local defined criteria which might include waiting time, priority, patient preferences. This needs to link with the requirements of eBooking where a scheduled activity is allocated through
Required Response
108.32 108.32.1
108.32.2
108.32.3
108.32.4
108.32.5
108.32.6
108.32.7
FINAL 1.0a
Page 122 of 607
ICRS
Requirement eBooking processes, e.g. allocation of an out-patient appointment in secondary care from primary care. 108.32.8 Beds are a resource and shall be incorporated as a scheduled resource, to be managed and allocated as part of a bed management function. The service shall schedule a series of appointments at pre-defined intervals, for events such as an immunization, screening or surveillance according to the care programme defined for the patient. The service shall provide a pending or holding facility for patients who cannot be assigned a defined appointment slot. The service shall support the direct interface of scheduling functionality with local implementations of the national eBooking solution (see module 109). The scheduling function shall incorporate intelligent support to allocate slots based on local defined criteria including waiting time, p riority, patient preferences, etc. The service shall allow the maintenance of appointment schedules for particular treatment centres or surgeries as specified by the user. The service shall schedule, at predefined intervals, appointments for events such as an immunization, screening or surveillance according to the programme as defined by the user. People due for a screening or other appointment but who are unable to get an appointment due to sessions being fully booked shall be placed in a queue for the next available appointment. The service shall produce lists for treatment centres or surgeries with queues detailing numbers involved,
Required Response
Each bidder shall describe their approach to management and allocation of beds and scheduling of bed resources both within the health community and across the Cluster.
108.32.9
108.32.10
Each bidder shall describe the controls that may be applied, eg around the period of time that slots may be held.
108.32.11
108.32.12
108.32.13
108.32.14
108.32.15
108.32.16
FINAL 1.0a
Page 123 of 607
ICRS
Requirement with the option to produce a list of patients in the queue. 108.32.17 The service shall enable the user to set the rules governing the order of selection of people for treatment centres or surgery lists, e.g. prioritisation of appointments according to parameters such as age and the date of the due event. The service should have the facility to enable the user to temporarily suspend scheduling of a specific event for a cohort of people. Scheduling shall interface directly with local implementations of the national eBooking solution.
Required Response
108.32.18
108.32.19
Each bidder shall describe how their scheduling solution supports complex scheduling arrangements such as Radiotherapy treatment scheduling.
FINAL 1.0a
Page 124 of 607
ICRS
109 - eBooking Overview This module specifies the requirements for the Cluster-level delivery of services to support eBooking. Scope Components The following components are required: Changes to Primary Care systems to make them support eBooking; and. Changes to Secondary Care systems to make them support eBooking.
Exclusions eBooking is a National Application to be provided by the eBooking NASP. The functionality required of that National Application is fully defined in a separate OBS, and this document does not attempt to reiterate this. Benefits and Outcomes Current Situation There exist a number of pilot sites, engaged in electronic booking of appointments. Desired Benefits and Outcomes The eBooking OJEC and the eBooking OBS detail the benefits and outcomes which are desired in connection with eBooking. From the Cluster perspective, each LSP is required to support the implementation of the eBooking project. Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Changes to support eBooking implemented by the LSP for those sites which are designated by the Authority. Minimum Levels to Be Achieved By December 2006 (Phase 2) Changes to support eBooking implemented by the LSP across the Cluster.
FINAL 1.0a
Page 125 of 607
ICRS
Overview Requirements Requirement 109.1 Overview Work to enable and support eBooking at the Cluster level is part of the LSP Services. Each LSP will be required to adapt relevant systems in accordance with the specifications provided by the eBooking NASP. Each LSP will be required to comply with national Message standards defined by the NDA. As part of the overall solution eBooking, it is intended that options LSP involvement in delivering supporting interfaces for the BMS retained. for for or are Required Response Each bidder shall describe its approach to delivering this module. Each bidder shall respond to the requirements identified for possible involvement in the delivery of the BMS.
The BMS provides a call centre service to provide an alternative or complementary route for booking transactions to be made. LSP involvement in delivery/supporting the BMS may be required to fulfil the following functions: deliver the eBooking application to the NHS call centre, data centres or desktops; project management of the integration of booking functionality into existing NHS call centres; and development and project management of further call centre services where existing capacity within a Cluster is exceeded. All of the above requirements would be undertaken in collaboration with the NHS. 109.2 Benefits and Outcomes Each bidder shall describe how it would deliver the benefits and outcomes from this module. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions.
109.3
Implementation and Phasing The overview delivery expectations have been set out above. More specific
FINAL 1.0a
Page 126 of 607
ICRS
Requirement implementation plans will be agreed with each LSP.
Required Response Each bidder shall describe which additional functions it would be able to deliver during Phase 1. The bidder must describe the responsibilities they would expect to be assumed by the Authority.
109.4
Detailed Requirements Requirement 109.5 109.5.1 Messaging The service shall generate a nationallydefined referral Message at the point of referral and submit this to external systems as required (e.g., the Spine or the eBooking System). The service shall generate a nationallydefined available capacity Message as requested by the eBooking System. The service shall generate a nationallydefined confirmation Message at the point the eBooking System makes an appointment. The service shall generate a nationallydefined cancellation Message to enable the eBooking System to cancel an appointment. The service shall generate a nationallydefined available capacity Message as requested by the eBooking System (see the eBooking OBS for details). Appointments Management The service shall support patient appointment booking for all scheduled clinical sessions taking place within a GP's premises, as defined in the NHS Accreditation criteria document, "RFA 1999 v1.2." The service shall support the electronic booking of appointments by patients, as Each bidder shall describe how it will address this requirement. Required Response
109.5.2
109.5.3
109.5.4
109.5.5
109.6 109.6.1
109.6.2
FINAL 1.0a
Page 127 of 607
ICRS
Requirement defined in the eBooking OBS. 109.6.3 The service shall support direct booking of appointments by patients via the internet and DiTV. The service shall support the electronic booking of appointments by patients as defined in the eBooking OBS. Specifically, the service shall be able to identify capacity that has been made available nationally (e.g., free diary slots for named consultants and/or clinics) and prevent this from being over-ridden at the Cluster level. Other Requirements The service shall provide a front-end to the national eBooking solution to enable bookings to be made into any facility covered by electronic booking from within the ICRS. The service shall interface with the national eBooking service directory to provide information from the scheduling function which will identify availability of slots for specific services. The service shall support an interface with eBooking service directory which will identify all appointments made through the electronic booking solution, linked to the referral identifier, enabling users to view, amend or delete appointments based on the referral identifier. The service shall provide information to the eBooking service directory which provides guidance on the booking rules which apply to specific services which can be booked through the electronic booking service. On selection of a service from the service directory through the electronic booking facility, the service shall check availability in real time of appointment slots at the chosen location for the chosen service. The local front-end to the electronic booking function shall invoke referral protocols which will provide guidance on referring to the service which is being
Required Response
109.6.4
109.7 109.7.1
109.7.2
109.7.3
109.7.4
109.7.5
109.7.6
FINAL 1.0a
Page 128 of 607
ICRS
Requirement booked and will link to the creation of a referral request or letter. The referral communication shall incorporate the booking reference number to enable reconciliation with the scheduled activity. 109.7.7 The service shall support the generation of a series of transactions between local ICRS scheduling systems and eBooking to enable the eBooking to find available slots and confirm and maintain bookings. The eBooking requirement will include a front-end that ensures bookings can be made into any organisations system without a user of the system having to be familiar with the technical environment. The LSP shall ensure access to this front-end from the ICRS. The eBooking Service shall regularly check the local ICRS scheduling system to maintain a record of what appointment slots are currently available. This repository shall also hold details of all appointments made, linked to the referral identifier, enabling users to view, amend or delete appointments based on the referral identifier. Once the user has made a choice from the service directory, the s earch engine shall also check the availability of appointment slots at the chosen location. The ICRS shall be responsible for creating the referral and passing this to the eBooking service, and may need to download information from the eBooking service (e.g. to print an appointment confirmation). There shall be a series of transactions between local ICRS scheduling systems and the eBooking service to enable the it to find available slots and confirm and maintain bookings. In addition, in the short term, there may be an on-line hypertext link to enable secondary users to access the system via legacy systems. Common criteria
Required Response
109.7.8
109.7.9
109.7.10
109.7.11
109.7.12
109.8
FINAL 1.0a
Page 129 of 607
ICRS
Requirement 109.8.1 Compliant Systems shall implement the messages listed under the "Common" section in the Message Interface Specification. Compliant Systems shall integrate with and utilise the ICRS Security Service. Compliant Systems shall integrate with and utilise the ICRS Transaction & Messaging Service. Compliant systems shall integrate as a minimum the following on connected Personal Computers in order to run the Electronic Booking application.
Required Response
109.8.2
109.8.3
109.8.4
a) HTTP and HTTPS protocol b) Internet browser Explorer web
c) Secure Sockets Layer (SSL) d) Ability to store Cookies

e) Ability to implement trusted
site certificates
109.9 109.9.1 Booker systems Message Interface Standards All Compliant Systems shall implement the messages listed under the "Booker Systems" section in the Message Interface Specification. Logon the booker system shall incorporate user authentication with the ICRS Security Service into its local authentication process so that the user only needs to log on once. The results of this authentication will be seamlessly passed from the booker system to the Electronic Booking application. Referral Booker systems shall provide a facility to allow the referrer to select the required information from the patient record stored in the referrer system for inclusion in the referral prior to the system sending message 011 ReferralLetter.
109.9.2
109.9.3
FINAL 1.0a
Page 130 of 607
ICRS
Requirement 109.10 109.10.1 Resource systems Message Interface Standards Compliant Systems shall implement the messages listed under the "Resource Systems" section in the Message Interface Specification. Appointment slot caching The Electronic Booking System shall request blocks of appointment slots from resource systems using message 009 GetFreeAppointmentSlots. The resource system shall be able to protect these appointment slots that are provided to the Electronic Booking System from being routinely booked by the local resource system. This may be achieved by Hard Locking or alternatively by marking the appointment slot so that it is clear to the user that booking the slot will make it unavailable to eBooking. In both cases it shall be possible for the user of the resource system to book the slot locally in which case the slot will be removed from the EBS appointment cache by sending a CancelAppointment message. Appointment slot booking The resource system shall be able to lock an appointment slot when booked by this message so that it is not available for booking locally (double booking). System identification Resource systems shall be identified to the Electronic Booking System by a unique system identifier. Service identification Resource systems shall have a system unique identifier for each Bookable Service. This identifier will be available to staff who are responsible for defining services to the Electronic Booking System. System authentication Resource systems shall facilitate system to system authentication with the ICRS Security Service.
Required Response
109.10.2
The rationale for this is that although actual slot booking is achieved by a real time message, caching of slots into eBooking allows users to browse available slots before choosing to book without unnecessary impact on resource systems or the network. This minimises network traffic when browsing slots and improves the usability of the application.
109.10.3
109.10.4
The Electronic Booking System will use this to look up the physical system address of the resource system.
109.10.5
The Electronic Booking System will subsequently use this identifier to cache and book appointment slots for specific Bookable Services from the resource system.
109.10.6
FINAL 1.0a
Page 131 of 607
ICRS
GLOSSARY
Bookable Service
A Bookable Service is a Service provided by a Resource that can be booked through Electronic Booking (i.e. the Service has bookable appointment slots within an Electronic Booking Compliant Resource System and the Service has been entered onto the Electronic Booking Directory of Services by the Resource). An end user system integrated into the Electronic Booking System used in booking services (e.g. GP System). A system that meets the criteria set out in this document. A system that meets the criteria set out in this document.
Booker System
Compliant System Electronic Booking Compliant Hard Locking
The process of making appointment slots sent to Electronic Booking physically unavailable for booking locally. This is in contrast to marking the slots as having been reserved for electronic booking but still available for booking locally, should this be required. The ICRS common service that provides user authentication, role based access control and encryption. The ICRS common service that provides the mechanism for transporting and routing messages between connected systems (e.g. EBS, PAS, Systems GP Systems). An end user system integrated into the Electronic Booking System used to provide services (e.g. PAS System). Any patient service provided by a healthcare organisation.
ICRS Service
Security
ICRS Transaction & Messaging Service
Resource System
Service
FINAL 1.0a
Page 132 of 607
ICRS
110 - Requesting and order communications Overview This module specifies the requirements for requesting and order communications. Orders are used to request services or goods, and may result in results being reported back (see Module 111 - Results Reporting). Orders may be fulfilled by electronic systems, manually, or by a combination of both. In order to deliver an order, whether it is styled as an order or request, the initiator may also need to take a sample or schedule a procedure. Requests can be placed for diagnostic and investigative services. This is not just for pathology/radiology tests, but also for other diagnostic services (e.g., audiology, cardiology, endoscopy, pulmonary function and neurophysiology) and for other goods and services. Scope Components The following components are required: Order definition. Order creation. Order routing. Sample collection. Order receipt. Order enquiries. Order management.
Exclusions Functions of systems for internal management of diagnostic and investigative services (see Module 114 - Diagnostic and Investigative Services Departments). Requests for services from Allied Health Professionals and other services may be dealt with under referrals (see Module 106 - Clinical Documentation, Including Clinical Noting and Clinical Correspondence). Pharmacy requests are dealt with in Module 113 - Prescribing.
Assumptions The ordering facilities within the LSP Services will need to integrate with existing departmental systems, such as pathology and radiology, which may be located at different sites within the health community. However, some parts of the health community may wish to pursue the implementation of new departmental systems.
Benefits and Outcomes
FINAL 1.0a
Page 133 of 607
ICRS
To: Patient Improved process and outcomes for patients/clients, resulting in better care. Improvement in quality of requests between different parts of the NHS and Social Care means fewer questions of the patient and fewer errors, resulting in improved confidence. Reduced turnaround time for some tests to be performed. Fewer requests lost or returned because information or routing is inaccurate. Accurate identification and return to the appropriate Clinician improves patient safety. Clinician: Clinicians/carers have a clearer view of what has already been requested or arranged for the patient as part of the agreed patient/client care plan. Improvement in quality of requests between Primary Care, Secondary Care, mental health and Social Care means fewer errors and less information is missing, resulting in improved fulfilment of requests. Reduced turnaround time for some results; and important results known sooner. Accurate identification and return to the appropriate Clinician improves patient safety. Manager: Optimisation of resource time within and across settings. Reduced risk of clinical incidents.
Scenarios (a) Managing Joans Chronic Illness and Leg Ulcers During the past 12 months, Joans own GP and the specialist GP in diabetes have been reviewing the regular investigations and results of home testing entered on the Patient Record by the patient. Joan has been referred to a dermatologist. A standard review set of orders can be triggered as soon as the patient is checked-in for her appointment. This triggers the need for a set of tests; although blood sugar levels do not need to be checked, since Joan had an appropriate blood test recently. However, other tests are needed, so Joans name is added to a work list for the phlebotomist in the clinic with appropriate documentation/advice for specimen collection and transport. A blood sample is taken from Joan and sent through to the laboratory. During the session, the doctor decides she needs a photograph of the ulcer. She requests the medical photographer to attend, to make sure the image is taken appropriately, and asks for copies to go to the GP. The GP/diabetic nurse is able to see orders placed by the consultant and does not need to repeat them. Both the hospital and GP doctors are alerted on receipt of the results.
FINAL 1.0a
Page 134 of 607
ICRS
(b) James Heart Attack During James stay in hospital, the staff are requesting investigations and services for him, including an echocardiograph, a chest X -ray, blood tests for lipid/cholesterol levels, and a lung function test. In general, these are triggered because James care is being delivered according to an ICP, but the staff have the discretion to tune the care plan and to perform additional tasks, including by requesting additional services.
(c) Mohamed Breaks His Leg Mohamed has been in hospital and his broken leg is on the mend, but he is due for follow-up. The GP practice can arrange this, when they call his mother at a local DTC. They are guided through the appropriate protocols to produce the request to the appropriate department in the DTC.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) All sites designated by the Authority must have had these requirements implemented by the LSP by the end of Phase I. Target for 2010 Full pan-community ordering procedures, either individually as part of order sets or within ICPs, guided by decision support functions, to be implemented by the LSP for the Cluster.
FINAL 1.0a
Page 135 of 607
ICRS
Overview Requirements Requirement 110.1 Overview Orders will be transferred using standards defined in Module 770 Clinical Communications. Use of NHS Number to identify patient in orders will be required, wherever possible. 110.2 Benefits and Outcomes The service shall enable the expected benefits and outcomes as set out above. 110.3 Implementation and Phasing The service shall meet the delivery expectations set out above. More specific implementation plans shall be agreed with each LSP. 110.4 Authoritys Responsibilities Each bidder shall describe how it would deliver the benefits and outcomes from this module. Required Response Each bidder shall describe its approach to integrating orders within the ICRS. Identify any requirements or limitations that might apply to integrating orders solutions with other components of the ICRS.
FINAL 1.0a
Page 136 of 607
ICRS
Detailed Requirements Requirement 110.5 110.5.1 Orders Defined The service shall enable orders to be defined (e.g., by name, effect, result expected, longer textual description/explanation, cost, etc.), and to be added to, modified or withdrawn, for any patient intervention within a care programme, as well as for nonpatient arrangements (e.g., laundry supply). There should be different definitions according to type of order. An order could also be placed for an action to be performed, such as a patient discharge. Orders can be for any good (even including home loan items) as well as services and activities. 110.5.2 The service shall enable local communities to configure the information required when an order is placed; e.g., by clarifying what is mandatory, how many fields are required, etc. This might be managed in a single Trust, a health care community or a Cluster. The service shall e nable routing and priority of an order, and any potential criteria for alerts need to be configured. Each bidder shall describe how it will achieve this, particularly when orders pass between different organisations or systems, including how non-computerised departments will be linked into systems. Each bidder shall describe the various types of repeating or cumulative orders supported. Each bidder shall describe how it will enable the secure creation, management and maintenance of order definitions, as well as the capabilities and flexibilities available for users. Each bidder shall describe how it will address the variety of order types, perhaps within a generic framework. (Note that orders have some level of similarity with prescriptions (see Module 113 - Prescribing) and referrals (see Module 105 - Integrated Care Pathways and Care Planning). Required Response
110.5.3
110.5.4
The service shall enable orders to contain: multiple order items; e.g., a blood test with multiple tests, multiple items of equipment for disability support; and repeated, cumulative or standing order items and/or order items which are to occur at specified dates/times.
FINAL 1.0a
Page 137 of 607
ICRS
Requirement 110.5.5 The service shall enable related orders to be grouped in order sets (potentially for different services), with the possibility of scheduling each request at different times or dates. The service shall enable orders to be linked to related protocols or procedures, defined nationally or locally.
Required Response
110.5.6
Each bidder shall describe how it will leverage any commonality. Each bidder shall explain how its proposed solution will enable orders to be automatically or manually linked to related protocols.
110.5.7
The service shall enable orders to be uniquely identified. Support shall be provided for noncomputerised departments raising or receiving orders. Order Creation The service shall enable orders to be raised (and results received): during a patient Encounter or at other times; and by an authorised person by selecting from a list of potential orders in context (e.g., patient condition/setting/previous result, or predicted effectiveness of treatment (e.g., antibiotic resistance)) or by copying an existing order. They shall also be able to over-ride any automatic suggestions. The choice, and any over-ridden suggestion shall be recorded in the Audit Trail. From a list of favourite or frequently used orders/requests. As selected from pick lists or found using text strings/text parser, suggesting alternative tests which are less expensive or less invasive for the patient (see Module 112 - Decision Support). Where suggested by decision support, automatically from the context and any patient circumstances (see Module 112 - Decision Support). Each bidder shall describe how it will meet each requirement while maintaining security and confidentiality.
110.5.8
110.6 110.6.1
FINAL 1.0a
Page 138 of 607
ICRS
Requirement Where triggered by workflow (e.g., care pathway or protocol by date/time), or another event (e.g., admission) or condition (including repeat orders). By the receiving department (e.g., reflex testing) if, in their judgement, additional work needs to be done. Costs and anticipated turn-around time shall be shown between alternatives. 110.6.2 The service shall enable each order to relate to a single patient, linked to an Encounter (e.g., an out-patient clinic visit) or to a single organisation (e.g., for ward stock). The service shall enable the initiator to request that an item, such as a copy of a result or alert, is sent to other people. It shall be possible to enable the initiator to provide additional information. The service shall enable ordering to be linked to booking/scheduling/ resource management, where necessary to request, book or schedule the appropriate resources. The service shall enable, where available, order data to be populated automatically from the Patient Record by decision support from other sources.
Required Response
Each bidder shall describe how it will meet each requirement; and, particularly, how it will relate the order to the patient/Episode or organisation.
110.6.3
110.6.4
110.6.5
Each bidder shall describe how it will integrate ordering to booking and scheduling to meet each requirement.
110.6.6
Each bidder shall describe how it will meet each requirement, enabling the various types of orders to be automatically created for, or suggested to, a user, within the overall security context.
110.6.7
Where appropriate, order data shall be encoded using standard coding (see Module 770 Clinical Communications). The service shall enable orders to be evaluated as they are being entered through decision support features; e.g., an advisory Message appears if a procedure or test being ordered was undertaken recently (see Module 112 Decision Support).
110.6.8
FINAL 1.0a
Page 139 of 607
ICRS
Requirement 110.7 110.7.1 Order Routing/Authorisation The service shall enable order data shall include routings of the order (including any required further authorisation), results, and any required alerts. The service shall enable orders to be routed to the responsible end users, organisations or systems. Authorisation can be for individual tests or batches of tests. Some orders shall require further checking and authorisation by an authorised person. The authorised person shall be able to amend, delete or add order data, return it to the originator with comments, or reject the order. The service shall provide the facility for the order to be re-routed, suspended or reactivated. Any such changes shall be recorded in the Audit Trail to satisfy the audit requirements of the agencies involved. The requestor shall be alerted of any such action. The service shall enable the authorised person to go on to schedule a requested service into an appropriate time slot. Orders shall be communicated using the national infrastructure and messaging standards, transforming to and from local legacy standards as appropriate (see Module 770 Clinical Communications). Associated material (e.g., specimens) shall be routed and tracked, and any risks (e.g., bio-hazards) associated with that material shall be highlighted.
Required Response
Each bidder shall describe how it will meet this requirement and enable this workflow, considering the potential variety of destinations and their different levels of automation.
110.7.2
110.7.3
110.7.4
110.7.5
Each bidder shall describe how it will meet this requirement and enable this workflow, including any transformation or translation which will be used.
110.7.6
Each bidder shall describe how it will meet this requirement and enable this workflow, taking into account the various types of order, material and destination.
FINAL 1.0a
Page 140 of 607
ICRS
Requirement 110.8 Specimens, Phlebotomy) Samples (e.g.,
Required Response
110.8.1
When an order is placed for a specimen or sample, the service shall enable the user to identify the types and number of samples, the appropriate containers and the appropriate means of transport. The service shall enable any physical material related to an order (e.g., specimens) to be identified and linked to the order. The service shall enable work lists to assist in the collection of specimens and samples. The service shall enable samples, specimens and other materials to be tracked, numbered and identified and kept with appropriate documentation, bags, etc. The service shall allow for the work list to be updated whilst the phlebotomist or other person collecting samples are on their rounds. This capability should include a level of urgency. The service shall enable authentication showing that the right sample has been linked to the right patient in response to the right order. The service shall include an audit trail to link the person collecting the specimen to the authentication process Order Receipt The service shall enable orders to be received by the responsible end user, organisation (department) or departmental system.
Each bidder shall describe how it will meet this requirement, including links with decision support, and including labelling or tagging of material, and how it is linked to the order.
110.8.2
110.8.3
110.8.4
110.8.5
110.8.6
110.8.7
110.9 110.9.1
Each bidder shall describe how it will meet this requirement, taking into account the various types of orders, materials and destinations.
FINAL 1.0a
Page 141 of 607
ICRS
Requirement 110.9.2 The service shall enable an authorised person receiving an order to view, validate and authorise it, potentially modifying the order or returning it to the requester for modification. The requester shall be alerted of any change or rejection ( e.g., if the sample is spoilt or lost in transit). The service shall enable authorised persons to select orders for processing, using selection criteria for filtering and ordering (see "Order Enquiries" below, at 110.10, for more detail). The service shall enable rapid matching of electronically-sent orders to physical samples. The service shall enable rapid matching of orders to appointments and patient attendances. Order Enquiries The service shall enable some orders to generate and return acknowledgements, in-progress information, and results and alerts (e.g., for blood tests (see Module 111 Results Reporting)). Others shall generate and return acknowledgements or despatch notes (e.g., goods orders). This is dependent on the order type, related protocols, and the receiving end user, organisation or system. The service shall enable results and alerts to be routed as defined by the order or related protocol. See Module 111 Results Reporting for more information on results. The service shall enable, where appropriate, the receipt of reports or alerts, or associated goods and material, to be acknowledged to the originator.
Required Response Each bidder shall describe how it will meet this requirement, taking into account both ease of use and security.
110.9.3
What criteria can be used for selecting orders, and how can pre-set criteria be defined and maintained?
110.9.4
110.9.5
110.10 110.10.1
Each bidder shall describe how it will meet this requirement taking into account the various types of orders, materials and destinations. Each bidder shall describe how it will enable these enquiries, the selection criteria and display/print formats.
110.10.2
110.10.3
FINAL 1.0a
Page 142 of 607
ICRS
Requirement 110.10.4 The service shall enable, where appropriate, orders to include the URL of a standard information set for that order. The service shall allow enquiries about orders, their status and results, to be made by authorised persons, using selection criteria for filtering and sorting, or using stored criteria which can be created and modified by authorised persons. It shall be possible to display or print the outcome of the enquiries. Order Management The service shall enable a means of housekeeping outstanding orders that have not been processed for lack of sample or because the patient did not attend. The service shall ensure that, in the event that the request is not accepted within a user-definable period, the unaccepted request is returned to the designated person. The service shall invoke escalation procedures. The service shall be capable of recording different statuses, including, but not limited to, the following: requested; dispatched; request cancelled; received by receiving department; receiving department redirected request to other department; receiving department rejected request; receiving department accepted request; investigation in progress; unauthorised reports available; authorised reports available; authorised reports updated/amended; previous request/reports for an investigation in a given time frame; the time the report is available; and the time the report was first viewed.
Required Response
110.10.5
110.11 110.11.1
Each bidder shall describe how it will meet this requirement.
110.11.2
110.11.3
FINAL 1.0a
Page 143 of 607
ICRS
Requirement 110.12 110.12.1 Further Requirements The service shall use integrated rules and knowledge based systems to assist and inform the ordering process. The service shall use sophisticated alerting mechanisms to communicate critical information to all relevant staff in a timely fashion. The service shall support the ondemand and automatic exception reporting of the status, in line with 110.11.3, of all orders/requests including the expected completion date/time. The service shall support the auditing of the progress of orders and responses. The service shall support the full integration of order communications with results reporting. There shall be no technical reasons (e.g. database design) that preclude the full operation of the many-to-many relationship of an order(s) with a result(s). The service shall support referrals for all care professionals to use specialised order templates designed to meet the needs of these (likely) noncomputerised departments to facilitate capture of patient information and reporting of actions taken/treatment given. The service shall support catering meal requests which include specialised order templates for a ward/location to place orders efficiently. The service shall support orders for patients to be placed on a group basis.
Required Response
110.12.2
Each bidder shall describe how information would be communicated to staff, and how quickly this might be achieved.
110.12.3
110.12.4
110.12.5
110.12.6
110.12.7
110.12.8
FINAL 1.0a
Page 144 of 607
ICRS
Requirement 110.12.9 The service shall support alertsreceipt of alert information from a performing department back to the originator to have the facility to record who has viewed the alert and who has taken action on the alert. The service shall enable order urgency/priority to be user-defined and to allow the high priority orders to be performed first by the receiving department. The service cancellation patient death some orders mortem. shall provide automatic of orders/activity on but shall recognise that may remain valid post-
Required Response
110.12.10
110.12.11
110.12.12
The service shall incorporate decision support inappropriate orders should be flagged on clinical grounds (e.g. order should not be placed for that patient due to allergy, diagnosis), sequencing (e.g. one particular order shall always be preceded by other specific order(s)), test contra-indication (e.g. the existence of another order within a specified time period precludes the current order being placed), duplication (the same order has already been placed within a (user-defined) time period). Over-riding of the advice shall be allowed in some circumstances and, if allowed, an audit trail of user details shall be kept. The service shall support messages for out-of-hours processing. Special arrangements or long expected completion time for a specific order should be displayed when a order is n placed to allow the users to decide whether they wish to take alternative action. The service shall support special arrangements and/or circumstances about specimen collection (e.g. small specimen volumes for paediatric patients) to be notified to the performing department.
110.12.13
110.12.14
FINAL 1.0a
Page 145 of 607
ICRS
Requirement 110.12.15 Until such time as scheduling of tests and examinations are fully integrated with departmental or universal scheduling systems the service shall provide full information to the requestor on the details of the scheduled arrangements which shall be provided by direct acknowledgement to the requestor of when a requested service, examination, etc. is to be performed. The service shall enable a favourites list to be created for each user as an alternative order selection method. The list will be based upon both the history of order placement and a direct user definition. Set-up and Management The service shall enable the creation and maintenance of a comprehensive catalogue of orders, services and requests that users can place on performing locations/personnel. The service shall enable the set-up of a catalogue of tests using active set -up support such as sophisticated wizards to assist users in adding or modifying elements of the catalogue. The service shall have the ability to accept a pre-existing catalogue of orders/requests from a central source and then be tailored according to local preferences and groupings. The service shall ensure where departmental systems functionality is provided as part of the overall ICRS solution that departmental systems/modules provide full status reporting of specimen receipt, status and expected completion date/time.
Required Response
110.12.16
110.13 110.13.1
110.13.2
110.13.3
110.13.4
FINAL 1.0a
Page 146 of 607
ICRS
Requirement 110.13.5 The services shall support the ordering of equipment which is required for a particular patient. This will include ordering from community equipment stores which may be run by healthcare providers or local authorities. ordering of fitted appliances, wheelchairs, incontinence products and such like.
Required Response
Selection of equipment will be provided from an electronic catalogue available to the requester. Where appliances needs to be fitted or made to measure the services shall support the scheduling of the patient for a fitting as part of the order process. The services shall enable equipment to be scheduled for delivery and installation. The services shall support the ability to request guidance information for the patient in use of the equipment. The services shall support the ordering of maintenance for this equipment and for collection when it is no longer required. A record of issue of equipment shall be recorded against the order. The services shall support the ordering of equipment direct from external suppliers where t hese are identified and interfaces can be supported. The service shall support the ordering of services, particularly home care services, against an identifiable contract which may be for an internal or external service.
110.13.6
110.13.7
FINAL 1.0a
Page 147 of 607
ICRS
Requirement 110.13.8 The services shall enable orders to be related to the role of the person placing the order. There shall be controls relating to the specific types of services particular roles can order, incorporating, where appropriate, limits on quantity, value or specific clinical requirement and in what quantities, and provide authorisation processes to deal with exceptions.
Required Response
FINAL 1.0a
Page 148 of 607
ICRS
111 Results reporting Overview This module specifies the requirement for results reports to be made available to the requestor and/or other authorised persons, including the patient. Results are generated by diagnostic and investigative services. They are generally provided in response to orders/requests (see Module 110 Requesting and Order Communications). Results may be generated by electronic systems or be provided manually, or by a combination of both. There is some overlap between this function and clinical documentation (see Module 105 Integrated Care Pathways and Care Planning); e.g., some departments may provide a summary of progress or outcome (e.g., on discharge). Results can be provided by a range of departments; not just by pathology/radiology departments, but also by other services (e.g., audiology, cardiology, pulmonary function and neurophysiology). AHPs and other services are dealt with under referrals and summaries (see Module 106 Clinical Documentation, Including Clinical Noting and Clinical Correspondence). Scope Components The following components are required: Results definition. Results generation. Results reporting. Reports and alerts routing.
Assumptions The results facilities within the ICRS may need to integrate with existing departmental systems, such as pathology and radiology, which may be located at different sites within the health economy. However, some parts of the health economy may wish to pursue the implementation of new departmental systems/functionality within ICRS that generates results.
Benefits and Outcomes To: Patient Improved process and outcomes for patients/clients. Reduced turn-around time for test results; and important results known sooner. Reduced number of re-tests, as results can be found even if the paper record is missing. Clinician
FINAL 1.0a
Page 149 of 607
ICRS
Clinicians/carers have clearer view of agreed patient/client care plan, as they can see the results that have led to chosen care plan or action; e.g., fractures visible from X-rays or high lipid scores clear from blood test. Improvement in quality of results completeness and possibly clarity (coding). No need to transcribe between Primary Care, Secondary Care, Tertiary Care, mental health and Social Care. Reduced turn-around time for test results; and important results known sooner. Reduced time searching for patient information by health professionals. Reduction in unnecessary retesting. Manager:
Optimisation of resource time within and across settings.
Scenario Blood Test (a) Managing Joans Chronic Illness and Leg Ulcers During the past 12 months, Joans own GP and the specialist GP in diabetes have been reviewing the regular investigations and results of home testing entered by the patient into her Patient Record. The diabetic specialist nurse and GP can be alerted when specific results are not as they should be. They can send the result to Joan via her own myhealthspace with advice for the further management of her diabetes and blood pressure.
(b) James Heart Attack During James stay in hospital, the staff have access to the results of tests, including echocardiograph, chest X-ray, blood tests for lipid/cholesterol levels, and a lung function test. Some of these results are summarized into a communication with the GP and the community cardiac rehab team. Progress of various results can be tracked graphically during James' recovery. When James requires treatment while on holiday abroad the following year, the doctor he visits has access to the recent results through James' myhealthspace.
(c) Mohamed Breaks His Leg The image of Mohameds mending leg is sent to be included in a reporting session run at the local hospital. The result comes through, and the all-clear is given from the practice. Mohamed can start games at school, and he can show his classmates a copy of his X -ray, which has been posted in his myhealthspace.
FINAL 1.0a
Page 150 of 607
ICRS
Minimum Level to Be Achieved by December 2004 (Phase 1) Integration of existing products from Module 770 Clinical Communications, so that existing results are available much more widely. Minimum Level to Be Achieved by December 2006 (Phase 2) Target that all other types of results and reports be available from diagnostic services, with images being provided by PACS, and direct links from clinical equipment. Target for 2010 The main focus of this module relates to results. In the longer term, this will include facilities such as remot e reporting via the use of electronic dictation; intelligent alerting of individuals, depending on the nature of the result; and the triggering of activities if action is required. The aim is to support full order communications (see Module 110 Requesting and Order Communications). Overview Requirements Requirement 111.1 Overview Results will be reported, and alerts raised, using standards defined in Clinical Communications module 770. Use of NHS Number to identify patient in results wherever possible. 111.2 Benefits and Outcomes The service shall enable the expected benefits and outcomes as set out above. 111.3 Implementation and Phasing The service shall meet the delivery expectations set out above. More specific implementation plans shall be agreed with each LSP. 111.4 Authoritys Responsibilities Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority. Each bidder shall describe how it would deliver the benefits and outcomes from this module. Required Response Each bidder shall describe its approach to integrating results within the ICRS. Identify any requirements or limitations that might apply to integrating results solutions with other components of the ICRS.
Detailed Requirements 111.5 Results Definition
FINAL 1.0a
Page 151 of 607
ICRS
Requirement 111.5.1 Results shall be returned for certain types of orders (see Module 110 Requesting and Order Communications). Their nature/structure can be defined by structure and content, be a straightforward opinion in free text, or even an image or recording. The service shall enable a relationship to be maintained between an order containing multiple order items, and thus multiple result items (e.g., a blood test with multiple tests items, each generating results). The order (or related protocols) shall indicate whether results shall be reported individually or as a group. Alternatively a number of order items can be satisfied with a single result (e.g., a series of X-rays both knees and elbows can be dealt with in one result text). The service shall enable related orders to be grouped in order sets (see Module 110 Requesting and Order Communications). Order sets (or related protocols) shall indicate whether results shall be reported individually or as a group. The service shall enable related orders to include repeated or cumulative order items; e.g., hourly tests and thus repeated results. The order (or related protocols) shall indicate whether results shall be reported individually or as a group. Each result shall relate to a single patient, and can be linked to an Encounter/event/Episode (e.g., outpatient or GP visit) and/or location/organisation (e.g., ward mainly in the case of a non-patient order). Results shall include raw data, interpreted and aggregated data, formatted data, and alerts based on application of rules to data.
Required Response Each bidder shall describe how it will meet this requirement, addressing the variety of result types, perhaps within a generic framework.
111.5.2
111.5.3
111.5.4
111.5.5
Each bidder shall describe how it will relate the results to the patient/Episode or organisation.
111.5.6
FINAL 1.0a
Page 152 of 607
ICRS
Requirement 111.5.7 It shall be possible to associate results with normal ranges, which themselves can vary depending on other factors, such as patient age/sex/weight. Results shall also include intermediate alerts to report the status of a result.
Required Response
111.5.8
Each bidder shall describe how it will identify alerts through defined criteria, and how those criteria can be defined and maintained by authorised persons. Each bidder shall describe how it will meet this requirement while maintaining security and confidentiality, including labelled or tagging of material, and how it is linked to the result. Each bidder shall describe how it can manage retention of samples or recording of their destruction.
111.5.9
The service shall enable orders to be received from, and results reported to, any location (subject to security considerations), including authorised external agencies.
111.5.10
Any physical material related to an order or result (e.g., specimens) shall be identified and linked to the order or result.
FINAL 1.0a
Page 153 of 607
ICRS
111.6 111.6.1
Result Generation The service shall enable results to be generated as a result of receipt of an order, or as a consequence of some timing, event or condition specified in a repeat or standing order. Each bidder shall describe how it w meet ill this requirement: to enable results to be automatically created, as a result of specified order criteria, and how those criteria can be maintained securely; to enable results to be securely transferred from automated systems; to take into account both ease of use and security, and how validation will be performed; to enable this workflow; to store the results data, and link it with order and patient data the actual generation of reports to be addressed below; and to generate progress alerts/updates, including defining and maintaining criteria for alerting.
111.6.2
The service shall enable results to be generated automatically from computerised functions or entered manually directly into the system. The service shall enable results to be entered manually only by an authorised user, and shall be subject to validation on entry, based on the order and related protocols. The service shall enable results to be (optionally) subject to verification, validation and authorisation by an authorised user before being reported, based on the order and related protocols. Unverified results shall be flagged as such. Generated results shall be stored, and together with order data and Patient Record, shall be used to populate the results report. Alerts/system updates shall be generated to indicate result progress, as defined by the order or related protocol.
111.6.3
111.6.4
111.6.5
111.6.6
FINAL 1.0a
Page 154 of 607
ICRS
111.7 111.7.1
Result Reporting Result reports shall be based on a format identified by the order (or by related protocols), as defined by a national standard (from NSF, best practice, etc.) and/or locally customised. The template that results shall define the data, format, style and routing of a results report, and set any potential criteria for alerts. Each bidder shall describe how it will meet this requirement: for the variety of possible reports; taking into account both ease of use and security; to enable templates to be automatically selected as a result of specified criteria, and how those criteria can be maintained securely; including any transformation or translation which will be used; and taking into account the various types of report, material and destination.
111.7.2
There shall be different definitions according to type of order or result. The service shall enable new definitions to be added, and definitions to be modified or deleted, by authorised persons. A report template shall be automatically selected based on the order or related protocols. An authorised user shall select from a list of potential reports templates, and can over-ride any automatic selection. The choice, and any over-ridden selection, shall be recorded in the Audit Trail. Where available, report data shall be populated automatically from the order or Patient Record (e.g., identifiers); from the generated results; from data passed in the workflow (e.g., care pathway); or by data suggested by decision support (e.g., likely causes for generated results or normal ranges). Cumulative data shall be added from previously created reports, if necessary.
111.7.3
111.7.4
111.7.5
111.7.6
FINAL 1.0a
Page 155 of 607
ICRS
111.7.7
The service shall enable an authorised user to amend, delete or add report data. The data populated, entered and overridden shall be recorded in the Audit Trail. If users have seen the previously unamended result, they shall be alerted that an update has occurred. Alerts shall be raised for exception conditions (as determined by the order, related protocol or report template). Results can be classified as urgent, even if the request was not. Where appropriate, report data shall be encoded using standard codings (see Module 770 on moving from locallydefined codes and Read Codes to SNOMED, etc.). Reports shall be stored and routed to the appropriate destinations (see below). The service shall enable reports to be resent on request. The service shall allow enquiries about results and their status and results to be made by authorised persons, using selection criteria for filtering and sorting, or using stored criteria which can be created and modified by authorised persons. It shall be possible to display or print the outcome of the enquiries. The service shall allow results to be viewed by users in a number of ways to suit the user group and to provide a wide variety of different views, such as: A patient view; e.g., a summary of a patients results (all of the information contained in a laboratory report, including the units and normal range for a result, and comments, current at the time of reporting). The normal range shall be patientspecific. Access to more detailed information for that patient by drill down and search facilities for this Episode/problem and complete history. Each bidder shall describe how it will enable these enquiries, the selection criteria and display/print formats.
111.7.8
111.7.9
111.7.10
111.7.11
11.7.12
FINAL 1.0a
Page 156 of 607
ICRS
A Clinicians view; e.g., all investigations by a specified time period requested by the Clinician or on a ward; all outstanding investigations; all investigations for a patient; all investigations for patients for whom they are responsible. Those results for a consultant team/practice which have been seen/not been seen by the Clinician. Investigations by service department; e.g., all laboratory medicine investigation results. Access to detailed information regarding requesting items; for example, sample types required for laboratory medicine investigations.
111.7.12
Selected results shall be capable of being displayed in a cumulative fashion. Results shall be capable of being shown as tables and graphs. The service shall appreciation of results. allow rapid
Results shall be grouped in natural ways; for example: by department, such as haematology or histopathology; by system (e.g., renal function, bone profile, liver function); as cumulative results; as tables; and as graphs.
Abnormal results shall be highlighted. Results that differ or contradict previous orders shall be highlighted.
FINAL 1.0a
Page 157 of 607
ICRS
111.7.13
Results reporting shall link to booking/scheduling/resource management, where necessary, to update the status of appropriate resources (e.g., test equipment freed up), or where the need for an appointment with a Clinician is triggered by the availability of the results. Reports and Alerts Routing The definition of the order and the data entered at the time of ordering shall include the expectations of notification of completion and how, where and to whom reports and alerts shall be returned. This includes copies to other recipients and rules for escalation if the result is not seen or acted upon within a given time period.
Each bidder shall describe how it will integrate results reporting to booking and scheduling to meet this requirement.
111.8 111.8.1
Each bidder shall describe how it will meet this requirement: considering the potential variety of destinations and their different levels of automation, including how non-computerised departments will be linked into systems. How will alerts be communicated? how the bidder will enable this resulting workflow, and associated audit arrangements; including any transformation or translation which will be used; and taking into account the requirements for retained samples/organs and the various types of order, material and destination.
111.8.2
Reports and alerts shall be routed to the responsible users, organisations or systems through workflow, e-mail, paging or other interfaces. The aim is to alert the Clinician to a particular result using an appropriate signal. They shall be routed to multiple destinations, including the Spine; however, in selected cases, sending all results to the Spine may need to be suppressed (e.g., ITU patients may have a constant stream of results which will only be acted upon locally). There shall be a sampling process for first, last, highest, lowest, or significant results may require the sending of only some reports or alerts. The service shall support computerised departments. non-
111.8.3
111.8.4
Some reports and alerts will require further authorisation (and optionally amendment) from authorised persons en route, so they shall be automatically routed to the appropriate end users.
FINAL 1.0a
Page 158 of 607
ICRS
111.8.5
If any report remains unaccessed for more than a given period of time (as defined by the order or related protocol), an alert shall be sent to the requester and any other specified end user, depending on the urgency of either the order or the result. Where appropriate, the receipt of the report or alert shall be acknowledged to its originator. Reports and alerts shall be sent in standardised Messages, related to the report template. Reports and alerts shall be communicated using the national infrastructure and messaging standards, transforming to/from local legacy standards as appropriate. Where appropriate, orders shall include the URL of a standard information set for that result. The service shall enable results to be sent to the patient and added to myhealthspace for the patient to access or share, although that may first need to be seen by a Clinician to ensure appropriate support is available, depending on the result. Any physical material (e.g., specimens) related to an order or result (e.g., samples) shall be identified, tracked and handled as defined in the order or related protocol (e.g., returned to storage or safely disposed of). This needs to link to systems recording disposal information, in line with the requirements of the Retained Organs Commission. The service shall allow Clinicians to mark the result as "acknowledged," as required, or tag the report with a digital signature. This will remove the need to print result forms that require a Clinicians handwritten signature. Further Requirements
111.8.6
111.8.7
111.8.8
111.8.9
111.8.10
111.8.11
111.8.12
111.9
FINAL 1.0a
Page 159 of 607
ICRS
111.9.1
The service shall provide full integration with departmental systems implemented in the high throughput diagnostic support departments (e.g. pathology) to receive orders and provide results of the tests ordered. In line with 111.6.2, the service shall provide a method of manually entering results for orders/requests placed for patients and locations (e.g. wards). The service shall support the use of integrated knowledge-based systems to assist the process of interpreting results. The service sophisticated communicate all relevant available. shall support the use alerting mechanisms critical result information staff as soon as it of to to is
111.9.2
111.9.3
111.9.4
111.9.5
The service shall support the on-demand and automatic exception reporting of the status of all results not read or acted upon by the originator of the request. The service shall be able to receive results from departmental systems together with the relevant normal range and alert criteria for that result/patient combination. The service shall ensure that the boundary of the departmental systems is recognised and defined to avoid the replication of generic functionality in departmental systems. The service shall support the requirement for requests to have an optional flag to indicate that the result should not be inserted into the patients electronic rec ord (and therefore be accessible by the other clinicians and the patient) until it has been seen by the responsible clinician (e.g. key cancer tests and HIV results). The service shall have the ability to receive results from any performing location wherever located without any manual intervention.
111.9.6
111.9.7
111.9.8
111.9.9
FINAL 1.0a
Page 160 of 607
ICRS
111.9.10
The service shall have the ability to provide results to any recipient (e.g. copy to a GP) wherever located without any manual intervention.
FINAL 1.0a
Page 161 of 607
ICRS
112 - Decision support Overview This module specifies the requirements for Decision Support. ICRS will enable Clinicians to make decisions based on the best-available patient information and currently-accepted evidence of best practice. ICRS will also provide managers with quality summarised data for service planning. Scope Components The following components are required: Elective structured access to reference material. Passive implementation of local protocols. Active alerts. Clinical management management and maintenance of protocols. Service development forward planning of clinical services.
Exclusions Information required for: research and development; statutory returns; and performance management.
Benefits and Outcomes To: Patient Safer care based on best evidence and local experience. Clinicians (and the patient) will have a common understanding of an agreed care pathway and associated protocols. Shorter length of stays. Less opportunity for drug errors. Fewer venepunctures and X-ray examinations. Clinician High availability of relevant information. Comfort of practising within agreed protocols (especially junior Clinicians). Efficient access to diagnostics, therapies, drugs and referrals. Ability to dynamically evaluate protocols and outcomes.
FINAL 1.0a
Page 162 of 607
ICRS
Much reduced administration (non-patient) time. Availability of valid teaching material. Manager
Access to quality service utilisation and outcome data. Improved dialogue with Clinicians, based on agreed data and protocols.
Scenarios A patient has n ecrotising fasciitis and is admitted as a surgical emergency. The surgical registrar and consultant anaesthetist consult the on-line ICRS knowledge service to seek the latest evidence on such cases. The decision is taken not to operate but to transfer the patient to a medical team for an antibiotic-based treatment. The medical team use pre-defined prescriptions for antibiotics to ensure the correct weight-related dose, combination and medication period. A patient is admitted out-of-hours with acute LVF. The junior houseman is advised through ICRS on the recommended diagnostic and therapy protocols for a 5-day expected stay. The houseman notes that the patient is on diuretics and the ICRS adjusts advisory electrolyte monitoring from every 2 days to daily. With the housemans authorisation, all diagnostics and therapies are locked into ICRS for automatic implementation. The staff nurse on a medical ward checks ICRS at the start of a shift and notes the tasks required for named patients, including medications a dministration. A complex infusion is required. ICRS offers advice on making up the infusion, plus offers an optional hypertext link to the manufacturers web site for further information. A medical team evaluates exceptions to protocols at their weekly review. The knowledge service provides a relevant, pre-determined search of relevant medical literature. This information is used to adjust the medical protocols and pathways that advise and guide all Clinicians in the team.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Integration of existing products from the Module 770 - Clinical Communications. Secure access to local electronic health libraries, medical and nursing school libraries, NeLH and the internet for full text journals, professional portals and reference material. Minimum Level to Be Achieved by December 2006 (Phase 2) Development of a managed knowledge service. Provision of end user analytical tools and data dictionary to interrogate and report on data entities in ICRS. Target for 2010 The main focus of this module relates to advice and guidance that must be available at points of patient care and clinical decision-making. This will develop in increasing sophistication with the clinical functions in ICRS, and is especially associated with orders, electronic prescribing and care pathways.
FINAL 1.0a
Page 163 of 607
ICRS
Overview Requirements Requirement 112.1 Overview Required Response Each bidder shall describe its approach to providing decision support within the ICRS and show how they plan to link that approach to the National Knowledge Service. Each bidder shall describe its approach to a developing evidence base. Identify any requirements or limitations that might apply to providing decision support with other components of the ICRS. 112.2 Benefits and Outcomes The expected benefits and outcomes have been set out above. 112.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. 112.4 Authoritys Responsibilities Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Detailed Requirements
Requirement 112.5 Elective Decision Support Knowledge Management (for clinicians this is described as Level 1 Clinical Decision Support) The service shall deliver evidence-based information to support clinical decisions and other services to support informed decision-making.
Required Response
112.5.1
Each bidder shall describe how it would integrate with the NeLH and NHSU.
FINAL 1.0a
Page 164 of 607
ICRS
Requirement 112.5.2 Knowledge to be managed as part of this service includes any health reference information; for example, published texts, formal journals or local research material.
Required Response Each bidder shall describe how access to published material will be provided. Each bidder shall describe how access to local reference information will be provided. Each bidder shall describe how it will provide maximum access to reference material from whatever source.
112.5.3
The service shall enable access to relevant sources of reference material: local medical libraries; medical and nursing school libraries; national resources, such as NeLH; and the internet. Secure access to NeLH and the internet for access to databases, journals, professional portals and other reference material. The service shall provide the ability to search for reference material using either formal search or simple browser methodologies, as required. Structured presentation of the latest reference material within a self-selected area of interest is required. Reference material pertinent to individual clinical resources (e.g., drugs, diagnostics, therapies, etc.) is required to be linked on a context-sensitive basis and to be able to be presented from screens referencing those entities.
112.5.4
112.5.5
112.5.6
FINAL 1.0a
Page 165 of 607
ICRS
Requirement 112.5.7 The service shall alert clinicians and managers when key new guidance and policy in their area of interest becomes available. In some cases this should include a read receipt capability. Passive Decision Support Embedded Guidance(for clinicians this is described as Level 2 Clinical Decision Support) The service shall provide facilities for passive decision support. Passive decision support is the evidencebased guidance that is embedded into order sets, formularies, protocols and pathways. Individually, these are described in greater detail elsewhere in this document. 112.6.2 Order sets, formularies, protocols and pathways describe best practice but are for guidance only. Clinicians shall be able to over-ride or ignore these tools and have access to the native ICRS functions and catalogues for orders, prescribing and documentation. The service shall flag, for later interrogation and reporting, all clinical interventions and investigations associated with exceptions to order sets, formularies, protocols and pathways. The service shall provide facilities to ensure that certain exceptions raise an alert. Decision support guidance is usually associated with an individual speciality, profession or practice; however, patients are often cared for by a number of clinical teams in any one Episode. Organisations must be able to construct, edit, delete and report on decision support rules and usage.
Required Response Each bidder shall describe how it will meet this requirement.
112.6
112.6.1
Each bidder shall describe how these decision support tools are applied to ICRS functions.
112.6.3
112.6.4
112.6.5
Each bidder shall describe how it will accommodate multiple-decision support guidance to create a single patientfocused guidance.
112.6.6
Bidders are asked to describe how decision support tools are maintained by users and what syntax is used within these tools (e.g., Arden).
FINAL 1.0a
Page 166 of 607
ICRS
Requirement 112.6.7 Order sets, formularies, protocols and pathways may be automatically and temporarily adjusted in response to a predefined set of recorded events (branching). Changes to decision support must be controlled and auditable with a date time stamp and a verified identification of the person making the change. The service shall allow changes to be made at different levels. They will include individual clinician, local unit, clinical network or national levels depending on the authority of those making the change. Active Decision Support Alerts (for clinicians this is Level 2 decision support -alerts The service shall alert Clinicians to any event or combination of events that is predetermined to lead to a serious clinical outcome.
Required Response Each bidder shall describe how it will meet this requirement and the depth of branching that is recommended.
112.6.8
112.6.9
112.7
112.7.1
Each bidder shall describe how it will meet this requirement: (a) where the event is Clinician-triggered (ordering and prescribing); and (b) where the event is patient-triggered (vitals or results, etc.). Each bidder shall describe how it will meet this requirement.
112.7.2
Alerts must be sensitive to patient presentation or history, clinical speciality or practice, location, time of day, or any other recorded parameter that is configured into the rules. Alerts shall be scalable, with different triggers and notifications. Bidders should be aware that Clinicians can be desensitised to frequent alerts. Prescribing rules shall be sensitive to results received which may impact upon the dose or appropriateness of a prescription. The service shall allow for speciality rulesbased prescribing.
112.7.3
112.7.4
112.7.5
FINAL 1.0a
Page 167 of 607
ICRS
Requirement 112.7.6 The service shall provide alerts when a decision is made to carry out an action that may contravene rules or expectations defined as part of the rules base, even though a care pathway/plan may have mandated the action. Examples include: the prescription of a drug to which the patient has an allergy; and ordering the move of an MRSAinfected patient to an inappropriate location
Required Response
112.7.7
The service shall ensure that alerts are generated in response to updated information becoming available, for example the results of a pathology test becoming available, where the result is out of range in the context of the patients condition. The service shall enable the direction of alerts to a variety of output devices (e.g. pagers, SMS text, email). This shall be configurable locally. The service shall enable the local configuration of suggested courses of action whenever a warning or alert is generated, and provide links to supporting documentary material. The service shall provide controls over how alerts are cleared. Generally they will stay visible until the action they are promoting has been carried out. They will be overrideable only by suitably qualified staff, and the reason will have to be entered. Overrides will be linked verifiably to the person making the decision. The decision support rules base shall extend to the application of non-clinical rules for example: to assist with the pre-selection of patients waiting for admission based on core criteria; to trigger alerts concerning a childs status on the child protection register; to identify a persons care status; and to identify a patients CPA status etc.
112.7.8
112.7.9
112.7.10
112.7.11
FINAL 1.0a
Page 168 of 607
ICRS
Requirement 112.7.12 The service shall enable the set-up of the rules base using sophisticated wizards to assist with clinical system management functions. The service shall provide a single repository of rules which operate across the whole ICRS solution. The services shall support the management of risk by generating communications and alerts where a failure to respond or take an action is identified. Examples of these situations are as follows: Where no answer has been acknowledged to a particular communication which requires an answer Where a task has not been completed within the designated timescale Where a patient has not attended a scheduled event which is designated as a high risk event.
Required Response
112.7.13
112.7.14
Bidders are asked to describe what facilities exist within the solution to assist care professionals in managing risk situations and supporting follow-up actions.
112.7.15
The service shall collate all alerts and overrides and present them in a locally definable way to senior clinical managers and clinical governance leads. This capability should include a tool to present the rate of different alerts and overrides over time. It should also include an ability to prepare pre-determined reports automatically and ad hoc reports as required. Level 3 decision support
112.7.16
The services shall incorporate level 3 CDSS. Level 3 CDSS collates clinical history, physical findings, physiological parameters and the results of investigations. It links the collated data directly to clinical decision making and informs integrated care pathways and care programmes.
Bidders must describe their current expertise of building level 3 CDSS systems and how they plan to develop that capability in the future to meet emerging needs.
FINAL 1.0a
Page 169 of 607
ICRS
Requirement 112.8 112.8.1 Clinical Management The service shall be capable of being interrogated and provide reports describing the detail of recorded exceptions to defined order sets, formularies, protocols and pathways, with any associated, user-defined, recorded outcome measures. A scripting tool shall be provided to build functionality and products. ICRS reporting functionality provided by the LSP shall provide a modelling capability, based on recorded activity, in order to evaluate the optimum protocol or pathway for a defined clinical presentation. Service Development The service shall be capable of being interrogated and provide reports describing anonymised and aggregated data on clinical activity and resource utilisation for particular clinical presentations, and patient and clinical groups. Templates, protocols and guidelines shall support the roles of the user. The service shall integrate with those tools which provide recognised decision support in particular contexts. For example, but not limited to, the Prodigy tool. The service shall enable decision support guidance systems for disease management offers advice on prescribing, referral, investigations, and offers additional support for the consultation, including: data collection, risk assessment, and display of patient data relevant to specific conditions. An example of such a system is Prodigy. Alert/Critical Information Screen The service shall permit the recording of patient-specific alert information; e.g., problems in the patients home, allergic
Required Response
112.8.2
112.9 112.9.1
112.9.2
112.9.3
112.9.4
112.10 112.10.1
FINAL 1.0a
Page 170 of 607
ICRS
Requirement reactions, aliases, spelling variations of the patients name, whether there is more than one patient of this name, and the patient's date of birth. 112.10.2 The service shall ensure that an alert flag is clearly displayed on appropriate screens. Access to the information behind the alert flag shall be visible to all members of staff with an appropriate level of authorisation. The service shall provide an interface to specific community services to provide electronic or paper-based updates on care received by a patient within an Acute Care setting; e.g., the provision of notification slips to Health Visitors following an A&E attendance by a child under 5 years of age. The service shall enable access to knowledge bases for community-based Clinicians in the same way as defined for the Acute Care sector at section 112.10.4, above. This shall enable access to sources providing information on equipment, treatments, services and patient services. It shall be possible to make the access to the knowledge context specific; i.e., directly relevant and appropriate to the content of the electronic record being viewed. Decision support shall evaluate the proposed order against patient data and the knowledge base to flag potential problems, identify potential duplicates (e.g., where recent test results are already available), suggest potentially better alternatives, additions, etc. Decision support shall include rules defined as national or local standards by authorised persons. Pharmacy Decision Support The area of decision support for prescribing, dispensing and administration is critical for patient safety. It also provides a very effective mechanism for medicines management across a health
Required Response
112.10.3
112.10.4
112.10.5
112.10.6
Each bidder shall describe how it will integrate ordering to decision support to meet this requirement.
112.11 112.11.1
Each bidder shall describe how it will integrate prescribing, dispensing and administration to decision support to meet this requirement.
FINAL 1.0a
Page 171 of 607
ICRS
Requirement care community. Areas include but are not limited to: formulary management; licensed use of drugs; allergies; interactions; contraindications; monitoring requirements pathology results checking; dose calculation; and specific management of, chemotherapy, IVs, TPN, and pharmacy in critical care and paediatrics;.
Required Response
112.12 112.12.1
Further Requirements The service shall enable access on demand to patient-specific information including attendances, appointments, orders and requests, reports and results of diagnostic procedures, drug prescriptions and administrations, diagnoses, procedures and documents created. The service shall facilitate dialogues between care team members in the course of managing a programme of care. This will range from quick access to phone/bleep numbers, through email and discussion threads, to access to videoconferencing.
112.12.2
FINAL 1.0a
Page 172 of 607
ICRS
113 Prescribing and pharmacy Overview Prescribing and administering drugs to patients is a key care process. Both processes, if inadequately informed, can also cause serious risks to patient safety. This module describes the core functionality required to allow and support the safe prescribing of drugs by Clinicians, as well as assisting in managing the dispensing and administration of drugs (mainly in the hospital setting), and monitoring and presenting each patient's drug history and compliance. Scope The scope of this module includes all prescribing and drug use across the NHS: in Primary Care; in 1 the Acute Care sector; and by community practitioners, as well as provision of drugs in the community. It does not cover t e functions of the community pharmacy systems in detail. Most h aspects are generic to all areas in this overview; but, where the need is specific to one sector, this is flagged with the item. Components Reviewing medication history prescribing. Prescribing. Repeat prescriptions. Decision support. Dispensing and administration.
Exclusions Logistics and financial processes (e.g., stock management and payments to pharmacies from PPA). Clinical functionality within community pharmacies and dispensing systems.
Assumptions Prescribing is core functionality for ICRS. Care events in which medicinal products are prescribed will feed into the Spine together with their content (e.g., current medication or prescriptions at discharge).
Other Requirements All prescriptions entered into the service shall have a secure electronic signature of the prescriber associated with them. Additional functionality for the secure electronic signature of the dispenser and person administering should also be provided.
This includes over the counter (OTC) drugs, "General Sales list drugs" (GSL) and "Pharmacy only" (POM) drugs and a range of other medical devices/ supplies/ medicinal products which are prescribed. This includes medicated bandages and blood products
FINAL 1.0a
Page 173 of 607
ICRS
Prescriptions messaging standard and methodologies should be as provided in the module 770 - Clinical Communications The NHS Number must be used as a unique identifier for patients wherever possible. A national drug database covering all sectors - The service shall comply with the UKCPRS (which will be a component of SNOMED CT).
Benefits and Outcomes A reduction of errors by the availability of an accurate medication history (from all care settings) alongside the on-line notes, treatment charts, clinical knowledge bases, as well as automatic ordering and reporting of results delivered in other areas by the ICRS and Local Systems in all sectors. Replace mundane repetitive tasks with automated systems, thus freeing up time, which can be spent with patients or patient-focused tasks. Supporting/enabling clinical checking against drugs, patients pathology, allergies, foods and test ordering affected by drug therapy, etc. Clinical and financial Audit Trails to contribute towards clinical effectiveness, clinical risk management and financial risk management. Provide information to support evidence based medicine. Electronic prescriptions received direct by dispenser. A means to identify and reduce fraud. Audit of therapeutic decision-making and support where relevant. Improved formulary management. Enhanced reporting facilities leading to improved financial planning, procurement and planning. Enhanced educational opportunities.
Desired Benefits and Outcomes To: Patient Compliance with agreed treatment protocols to ensure that the patient is receiving the most appropriate therapy and eliminate idiosyncratic prescribing that may arise from locums or visiting medical staff. Improved patient safety, resulting from the reduction of prescribing, administration and dispensing errors due to legible prescriptions, reduced transcription errors, prescribing within agreed protocols, and decision support mechanisms. Reduced delays in providing discharge medicines (i.e. To Take Out (TTO) (known as To Take Home (TTH) or "To Take Away") medication.
FINAL 1.0a
Page 174 of 607
ICRS
Provision of a faster service from the pharmacy enabled by the electronic transmission of drug orders from the ward to the pharmacy department or community pharmacist and automated dispensing, which will result in fewer missed first doses. Improved care after discharge due to improved communication between primary and secondary care Clinicians on all aspects of a patients treatment within hospital. Increased level of uniformity of information about treatments together with the generation of compliance leaflets. The management of repeat prescriptions can be made much more convenient. Improved communication for unusual medicines etc e.g. unlicensed medications. Single Patient Record reduces medication errors. Clinician Pharmacists
Allows the pharmacist, pharmacy technician and pharmacy support staff to pursue much more patient-focused care with documented improvements in risk reduction. The system shall allow the currently prescribed drugs list, together with previous medication history and changes, to be reviewed at pharmaceutical clerking. Practice-, hospital- and community-wide formulary control and on-screen formulary notes. Improved adherence to treatment guidelines, such as the helicobacter eradication regimen. Reduction of ineffective treatments such as local resistance patterns of antibiotics. Reduced need for manual prescription screening and manual re-keying of all prescriptions. Clear and legible prescriptions. Work arrives in dispensary earlier or as part of a regular delivery, allowing better workload planning in all sectors. Automatic alerts when new prescriptions arrive allow central verification of orders with subsequent dispensing and stock control. In addition, with more ward based clinical care, more of this verification should be achieved at ward level. Support role in supplementary and independent prescribing; as well as other medication interventions such as patient group directions or altering therapy under pharmacy led medication review e.g. warfarin. Enhanced security, as system functionality can be confined to individual users and even individual drugs (users will only see those items at their security level). Complete Audit Trail of transactions. Reports of drug usage down to the individual patient level. Reports of drug usage by individual doctor (prescriber). Improved data to support DUR (monitoring of contra-indications, drug interactions). Support for repeat dispensing. Links to automated dispensing systems. Access to on-line information sources. Facilitation of medicines management processes at ward level e.g. reuse of patients own medications. Clinical interventions recorded in each patients record. Nurses
Clear, legible electronic prescriptions. Reduction of mundane tasks. Fast and easy identification of required medications within an administration period, together with the administration times and other adjunctive information. Support of their extended role in prescribing and facilitation of nurse prescribing formularies and prescription against controlled indications. Fast and easy recording of drug administrations. On-line advice relating to drug administration or the patient.
FINAL 1.0a
Page 175 of 607
ICRS
Ability to automatically defer medication until a later time if a patient is not on the ward during a drug round. Electronic warning system if any medications have been referred / deferred or if any administrations have not been charted within an administration period. Mass suspension of medications by patient, bay or ward, and for all or individual drug forms, with automatic resumption. For instance, if a patient is off the ward for any period of time, or if a patient is designated as being "nil by mouth," and the suspension of all oral medications is required. System will improve communication between teams and shifts. Automatic ordering of non-stock drugs with the ability to order manually items and on-line indication of the status of a drug order in the pharmacy supply chain. Ability to track prescriptions, with reasons for any delays; e.g., item out of stock, waiting for doctor to contact, transport delays, etc. Prescribers (including, but not limited to, GPs / hospital doctors / dentists / prescribing nurses and paramedics)
On-screen help with prescribing. Decision support mechanisms with tracking and outcome data, together with the ability to review prescribing habits and costs. Improved communication via the automatic production of referrals, out-patient letters, discharge letters, and the generation of an electronic out-patient prescription for immediate transmission to the GP practice. Automatic prescription generation for out-patients, so that the dispensary can fill a prescription before the patient arrives at the pharmacy to collect. The ability to re-initiate a previous prescription/dispensing transaction for either all or individual items. The system shall allow the currently prescribed drugs list to be reviewed at pharmaceutical clerking. Ability to prescribe from any terminal even remotely from the patient. Common standard regimes may be prescribed in one single order entry. Helps Clinical Audit. System increases communication between teams, particularly out-of-hours. Better visibility of patient medication requirements at discharge. Improved communication across all care settings. Guidance provided on NSF recommendations, and other national guidance e.g. NICE, for prescribing. Online access to clinical prescribing care plans for supplementary prescribing. Manager
Improved management of the drug budget. Improved information flows; e.g., PPA budget and prescribing management information. Potential improvements in compliance with agreed treatment guidelines within a PCT. Risk management opportunities increased. Reducing the opportunity for prescribing, hospital manufacturing, administration and dispensing errors. Ensuring compliance to agreed guidelines. Formulary control with ability to produce and monitor health economy wide formularies, leading to real reductions in the drug budget. Greater security. Identification of individual patient drug costs. Ability to support, through monitoring, clinical governance. Provision of robust prescribing and administration data. Fraud reduction.
Delivery Expectations.
FINAL 1.0a
Page 176 of 607
ICRS
Minimum Level to Be Achieved by December 2004 (Phase 1) Where electronic prescribing is implemented, any new system implemented during this period must deliver the level of functionality specified in this module. Minimum Level to Be Achieved by December 2006 (Phase 2) Prescribing catalogues must be created, linked to local guidance, national formularies and accredited pharmaceutical reference databases. Good progress must have been made towards live electronic prescribing across the care community. Target for 2010 All systems must deliver the level of functionality specified in this module, including specialist areas like chemotherapy, ITU and A&E. Overview Requirements Requirement 113.1 Overview Required Response Each bidder shall describe its approach to integrating prescribing within the ICRS. Identify any requirements or limitations that might apply to integrating prescribing solutions with other components of the ICRS. 113.2 Benefits and Outcomes The expected benefits and outcomes have been set out above. 113.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. 113.4 Authoritys Responsibilities Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Detailed Requirements 113.5 Reviewing Medication History
FINAL 1.0a
Page 177 of 607
ICRS
Requirement 113.5.1 The service shall provide a complete history of all community and hospital prescriptions (and dispensing/administration records where available) at the point of care, sorted by filters; including, e.g., by displaying current medication first or by recent changes made to prescriptions, discontinued prescriptions with notes relating to the reasons for change. Views of the record shall be user-customisable and suited to task, user role and location. The service shall comply with the requirements for the Spine to display medications. This is particularly useful within, but not limited to, allergy tracking. The service shall record all data in such a way as to facilitate flexible searches by drug attributes, as well as patient attributes and by indication. When the current prescription course has ended, it shall disappear from the current list although still be present within the medication history. The system shall allow for pharmaceutical clerking of patients. Intranet access to physical tablet identification software may be desirable. Prescribing The service shall record a prescription in a clear, unambiguous, precise and concise manner whilst adhering to all the required NHS standards.
Required Response Each bidder shall describe how it will meet this requirement. Including a description of the ways in which views can be configured.
113.5.2
113.5.3
How would the bidder ensure matches between locally-held and Spine-held medication data?
113.5.4
Each bidder shall describe how its system would meet this requirement.
113.5.5
Each bidder shall describe whether its solution meets this requirement.
113.5.6
Each bidder shall describe how its system would meet this requirement. How does the proposed Solution meet this requirement?
113.5.7
113.6 113.6.1
Each bidder shall describe how the system will operate such that it is not necessary to constantly reprint a medication record, to ensure minimum paper generation. It should be possible to print a hard copy prescription on request or if there is a legal requirement for prescriptions to be printed. How does the proposed service meet this requirement?
113.6.2
During the prescription (and dispensing/administration), the service shall enable validation against drug and patient details as an identity or clinical check.
FINAL 1.0a
Page 178 of 607
ICRS
Requirement 113.6.3 The system will facilitate the prescribing of a whole range of prescription and nonprescription item types and routes of administration. Where data is required to be collected about disposal of any items, the service shall support such collection.
Required Response Each bidder shall describe how the proposed service meets this requirement. In particular, each bidder shall list the type of drugs and medicinal material it would expect to include. Bidders should state, wherever appropriate, how they will deal with the stock issues of associated products; e.g., catheters, masks, syringes, needles, lines and connectors. Each bidder shall indicate how it would meet this requirement.
113.6.4
The service shall facilitate the documentation against patients or individual drugs of: the reasons / indications for drug therapy initiation and the reasons for an individual drug choice and/or the reason for rejection of a particular drug; notes added by user type; e.g., pharmacy to record interventions, or nurses and doctors notes; and the reasons for the discontinuation of a drug therapy.
113.6.5
Following selection of a drug, a prescription shall then be capable of including any factor required for dispensing and/or administration, such as dose (variable, sliding scale, reducing or static) form, strength, frequency, total quantity, etc, either individually entered at the point of prescribing or exceptionally edited by the dispensing pharmacist; or, preferably, as a part or fully pre-defined prescription, adhering to local formulary and/or prescribing guidelines, duration and specific details required for safety e.g. diluents, administration specifics etc. The service shall support the printing of prescriptions/FP10s or production of legally appropriate tokens, as may be defined. This requirement currently includes the printing of an FP10HP or equivalent) onto special stationery, including bar-codes. In secondary care, the prescription forms on the system shall mimic or improve upon the current charts wherever possible.
Each bidder shall indicate how it would meet this requirement.
113.6.6
113.6.7
FINAL 1.0a
Page 179 of 607
ICRS
Requirement 113.6.8 The service shall allow for prescribing by users other than doctors; e.g., via group protocols subject to manual over-ride by Healthcare Professional. The service will allow for prescribing by all supplementary and independent prescribers. The service will allow for recording of non prescription supplies i.e. those made under patient group directions or personal administration. 113.6.9 The service shall be able to record the validity period (e.g., when a prescription for antibiotics shall be reviewed), as defined locally, for prescriptions for various drugs. This shall include differing validity periods for different drugs. The service will also be able to determine whether there is an automatic stop or a warning that a review is required. The standard validity period for prescriptions shall be site-defined, with the flexibility to be varied by authorised personnel for specified drugs, patient type, specialty or other specific situations. Automatic stops may be required for certain drugs. The system shall provide the facility to notify the prescriber when the end of a validity period is reached. The service shall provide the facility to record drugs taken and administered and not stocked by pharmacy but brought in by the patient on admission to hospital or another facility. These shall be clearly marked as such on the patients electronic medication record. All prescriptions entered into the service shall have a secure digital signature associated with them. This shall include appropriate double authorisation when using digital signatures on specified drugs. All transactions shall be recorded in real time and be auditable. The service shall support prescribing by nurses and other health professionals in accordance with national requirements specified by the Authority.
Required Response Each bidder shall indicate how it would meet this requirement and the types of protocols managed.
Each bidder shall explain how validity periods are handled by the system.
113.6.10
113.6.11
113.6.12
113.6.13
Each bidder shall describe specific security and audit aspects for prescribing provided by its system.
113.6.14
FINAL 1.0a
Page 180 of 607
ICRS
Requirement 113.6.15 The service shall allow complex drug regimens to be prescribed and administered for all types of patient and location, including specialist prescribing in in-patients, Primary Care, out patients, A&E, chemotherapy, paediatrics, ICU or Special Care Baby Units, (SCBU), theatres, or in Community Care. The service shall adhere to and support current legislation around the prescription of all categories of controlled drugs, including handwriting requirements. The system should be adaptable to changes in legislative requirements and good practice guidance. The system shall offer a range routes to a selected drug, such as medicines index, and indication driven prescribing, in addition alphabetical list. of access a common / protocolto a full
Required Response Each bidder shall describe how its offering handle areas such as chemotherapy, IV infusions, TPN, variable doses, etc.
113.6.16
113.6.17
Bidders are required to describe how errors in drug selection can be minimised.
113.6.18
The service shall offer maximum flexibility on searches for drugs. Even though the service shall hold information about all drugs, when searching for a drug to prescribe the service shall display a pick list presenting drugs on the formulary first. Searching for a branded product shall also display the generic equivalent, where appropriate, sorted with generics appearing first. The service shall allow appropriate substitution but not allow inappropriate substitution. The service shall allow, where appropriate and legally permitted, the ability to prescribe "off formulary." All drugs onc e finally selected will be displayed by generic name first with proprietary name only being listed where this is pharmaceutically required. This ability should be restricted to key grades and roles, and shall include a requirement to justify the decision which shall be auditable.
Each bidder shall describe how the user would select drugs for prescribing.
113.6.19
Where an individual drug is selected, the system shall display any appropriate regimes or protocols in which that drug exists.
FINAL 1.0a
Page 181 of 607
ICRS
Requirement 113.6.20 The service shall allow prescribers to enter and prescribe any drug not included in the directory; e.g., clinical trial drugs, extemporaneous preparations, specials, unlicensed drugs and drugs brought in by the patient. Where this has been done, an immediate alert shall be sent to the appropriate duty pharmacist. This ability should be restricted to key grades and roles, and shall include a requirement to justify the decision which shall be auditable. 113.6.21 The service shall allow drug dosages to be prescribed without requiring the user to choose from actual drug strengths or formulations or pack sizes that may be held in stock. The use of this function is the exception rather than the rule. Where possible, each prescription shall be recorded against the condition / indication for which it is being prescribed. This is important for auditing purposes. The service shall comply with all national and locally-defined guidelines and legal requirements. It shall also respond to all changes in legislation and guidelines. Where appropriate the service shall provide the facility to view applicable guidelines and their source for example, but not limited to, NICE, NSF guidelines and local practice. 113.6.24 The drug directory shall contain and display appropriate fields.
Required Response Each bidder shall indicate how it would meet this requirement.
113.6.22
113.6.23
Bidders must list the national guidelines and legislation their solution will meet.
Each bidder shall describe the fields typically used to display drugs for the prescriber to select. Each bidder shall indicate how it would meet this requirement.
113.6.25
The service shall enable access to library files of local and/or district formulary information, WeBNF, prescribing guidelines and policies. (See Module 112 - Decision Support). The service shall support the recording of nonsystem generated prescriptions (e.g., handwritten and remotely-generated prescriptions). The service shall permit a prescriber or validator to add dispensing notes which are displayed and printed as appropriate.
113.6.26
113.6.27
FINAL 1.0a
Page 182 of 607
ICRS
Requirement 113.6.28 113.6.29 FP10 forms shall conform to the drug tariff. The service shall allow for the prescription and printing (not on FP10 forms) of private prescriptions and signed orders. The module shall automatically issue (i.e., print) relevant warning notices. The service shall provide the facility to support the prescribing, administering and recording of medications to the foetus so that the drug record produced forms part of both mother and baby records. The service shall provide on-line support for the process of prescribing.
Required Response Each bidder shall indicate how it would meet the various printing (and other alerting) requirements to support prescribing.
113.6.30
113.6.31
113.6.32
Each bidder shall describe the types of on-line support available to prescribers. Each bidder shall indicate how it would meet this requirement.
113.6.33
All alterations in prescribed treatment shall be dealt with by invalidating an entry and entering the new details. Information shall not be deleted. Details of changes shall be recorded on the medication record. The service shall allow the re-initiation of a previous prescription/dispensing transaction for either all or individual items. The service shall enable rules based, prescribing from an approved formulary. The service shall enable alert notification to be triggered from Patient Record or drugs database. The service shall ensure that either the complete or the appropriate part of the patient drug record including history is available across all healthcare settings incorporating dispensing and administration of drugs. The service shall enable effective and speedy search facilities across a variety of parameters i.e. drug name, drug type, previous use etc. The service shall provide for the initiation of repeat prescription of drugs by non-prescribers within a protocol defining the number of permissible repeats and the intervals between repeats. However, it can only be digitally signed by the prescriber.
113.6.34
113.6.35
113.6.36
113.6.37
113.6.38
113.6.39
FINAL 1.0a
Page 183 of 607
ICRS
Requirement 113.6.40 The service shall support the return of unused (particularly controlled) drugs in all relevant care settings. The service shall support handwritten prescriptions for controlled drugs where required. The service shall allow the validated overriding of prescribing protocols i.e. for trials, research specialist areas, with appropriate note addition detailing the reasons for the over-ride. The service shall enable the inclusion of any administration requirements i.e. with food, after food, prior to another event, etc. The service shall enable recording of summary information in an emergency situation. Timing flexibilities spacing infringements shall be highlighted. The service shall support calculation of appropriate paediatric dosage using a childs validated weight, body surface area and age. These are continually changing as the child grows and the dosages based on such calculations need to be regularly reviewed. The service shall support the use of such calculations for adult dosages within for example, but not limited to, chemotherapy. 113.6.47 The service shall support dose rounding for paediatric prescribing if appropriate or present the prescriber with a practicable dose and /or preparation for administration. After dose calculation the service shall then, if necessary, calculate and provide detailed instructions on how the dose should be administered. This will need to be incorporated into the administration information.
Required Response
113.6.41
113.6.42
113.6.43
113.6.44
113.6.45
113.6.46
113.6.48
FINAL 1.0a
Page 184 of 607
ICRS
Requirement 113.6.49 The service shall link to ICP, where relevant information on fluid balance is recorded with functionality, to support alerts where acceptable levels are breached in relation to drug dosage and administration. Safety checks will be built in to ensure that repeat doses or IV infusions are not given until required. The service shall support the production of an administration regimen, integrated into the patients care plan, for use in any care setting. The service shall support an alert notification triggered from within the Patient Record or from information held within the drugs database including missed doses. The service shall support the recording of prescriptions within a care plan such as eCPA for MH or for medication or dressings required by e.g. community nursing. The service shall support the use of approved formularies for different types of prescribers. The service shall support reporting procedures for incidents, allergies, adverse effects etc in all care settings. The service shall access approved formularies including those set to local requirements or specific for specific groups of prescribers. The service shall comply with requirements for reporting incidents, errors or adverse effects from prescribing and administration of drugs. The service shall comply with requirements for all datasets where prescribing is an element of the return. The system shall enable a link between a repeat prescription review and the results of patient self monitoring at home to authorise automatic dispensing of the medication. In some cases this loop may include a clinician authorisation step (e.g. a specialist hypertension nurse reviewing weekly readings) or it may be automated.
Required Response
113.6.50
113.6.51
113.6.52
113.6.53
113.6.54
113.6.55
113.6.56
113.6.57
113.6.58
FINAL 1.0a
Page 185 of 607
ICRS
Requirement 113.6.59 The system shall enable a prescription to be delivered electronically to a pre-determined pharmacy or a remote central mail order pharmacy. The service shall enable patients to self dispense in hospital. It should include the capability to record the number of drugs that patients have either brought into hospital or been dispensed and to count down and reorder before they run out. It should be possible to readily tell how many doses of a specific drug that the patient should have left in order to monitor and support compliance. In relation to IV infusions the system should link to patient safety systems integrated with infusion devices Discharge from Hospital The service shall provide facilities to produce a discharge prescription on or before discharge, with a suitable report for the patient to take to the dispensary in advance of actual discharge, if necessary. At the time of discharge, the service shall compare the TTO list with the list on admission (the list on the Spine). If any drugs have been stopped / added / changed during admission, the prescriber shall be prompted to give a reason. This reason shall be transmitted to the GP on discharge along with details and indication for use for any new drug therapy. In addition where the patient has identified a community pharmacist, transmit the same information to the community pharmacist. The information should indicate the intended length of treatment and whether further prescriptions.supplies are to be made by the hospital or in the community. If the treatment is subject to a shared care protocol this information should also be communicated at the same time. The system shall allow for an FP10-initiated supply, with the subsequent transmission of data as required. The service shall facilitate dispensing for discharge as supported by the NHS Plan pharmacy in the future.
Required Response
113.6.60
113.6.61
113.7 113.7.1
Each bidder shall describe how its proposed solution meets discharge and short -leave medication requirements.
113.7.2
113.7.3
113.7.4
FINAL 1.0a
Page 186 of 607
ICRS
Requirement 113.7.5 At the point of discharge, the service shall be able to convert a current in-patient prescription into a TTO or weekend leave. In this process, the service shall be aware of drugs prescribed and brought in by the patient. The service shall provide the usual checks to ensure that each item is authorised and reviewed. Weekend leave will require a record of the time of discharge and time of return. The system will then work out which medications need to be administered (and therefore dispensed) for that time. The service shall allow for the prescribing and subsequent dispensing of short leave drugs; e.g., less than one day. There shall be a facility to add new (i.e., previously un-prescribed during in-patient stay) drugs to a discharge order. The system would include PRN Medications by exception only on a discharge order. The system will take account of all items on the order, including the patients own drugs, when creating the discharge order for dispensing or not as the case maybe by the pharmacy. The service shall provide an alert if the patient is going back into nursing / residential care as it may not be necessary to supply drugs for the full duration of treatment. 113.7.11 The service shall have a facility to include time and/or urgency of discharge on the prescription transmitted to the pharmacy. The service shall have the facility to record the priority of a discharge prescription. The service shall recognise the legal requirements for prescribing controlled drugs on discharge. The service shall allow for review and subsequent amendments of TTO prescriptions up to the time of processing/validation by the pharmacy.
Required Response
113.7.6
113.7.7
113.7.8
113.7.9
113.7.10
113.7.12
113.7.13
113.7.14
FINAL 1.0a
Page 187 of 607
ICRS
Requirement 113.7.15 The service shall notify prescribers when the pharmacy is closed so that the pharmacy can process urgent TTOs. The service shall record the name of the Clinician who has discharged the patient and provide the facility to record a handwritten signature for every item and the overall discharge. The service shall support prediction of date / time of discharge to facilitate effective discharge planning of, for example, transport, etc. Out-Patients The transmitted prescription shall record the prescriber and the clinic of origin. Transmission of medication group rather than specifics shall also be allowed for areas that do not do outpatient prescribing / dispensing. The service shall allow dual roles to be available i.e. prescribing in urgent need (separating out pre-defined hospital only items from community pharmacy dispensing) and for referral info as above. 113.8.2 The service shall have the facility to record priority of an out-patient prescription; e.g., in the case of transport. The service shall recognise the legal requirements for prescribing controlled drugs. The service shall allow for review and subsequent amendments of prescriptions up to the time of processing/validation by the pharmacy. The service shall notify prescribers when the pharmacy is closed. The service shall have the facility to print a hard copy of the prescription, including an FP10HP, onto special stationery.
Required Response
113.7.16
113.7.17
113.8 113.8.1
The bidder must describe how it would support out-patient prescribing.
113.8.3
113.8.4
113.8.5
113.8.6
FINAL 1.0a
Page 188 of 607
ICRS
Requirement 113.8.7 Prescriptions raised in out-patient areas will be automatically generated and, where indicated, will be communicated directly to the dispensary immediately following authorisation. The service shall transmit prescriptions to predetermined locations. Prescriptions times drug regimens for out patients will be communicated to the relevant pharmacy section in such a way as to ensure that the drug is available on all dates required by the regimen.
Required Response
113.8.8
113.8.9
113.8.10
The service shall interface with waiting time software or record waiting times and produce / owing slips. There shall be a validated facility to highlight (by age, condition and previous records) whether a patient is exempt from paying prescription charges. Capture patient signature whether paying or exempt. The service shall transmit prescription information to retail pharmacies and GPs and / or allow them to view the required information. Where particular potential danger of error exists such as in the administration of intrathecal medication for cancer patients, the service shall support a major potential error alert system and auditable identifiable cross checking. In relation to the administration of intravenous drugs and on other occasions when particular potential danger exists for the patient, the service shall support a cross checking system linking drug, patient, prescription, time and person administering the drug e.g. bar coding systems. In the event of an adverse event, the service shall enable real time reporting of the event.
113.8.11
113.8.12
113.8.13
113.8.14
113.8.15
FINAL 1.0a
Page 189 of 607
ICRS
Requirement 113.8.16 In the event of the patient developing an adverse reaction to a drug, the service shall prompt the clinician to grade the reaction for its level of seriousness at the time and for the future and record that in the patients NHS spine data. The service shall create an alert is created should the drug or any similar drug be prescribed in the future. In the event of a patient developing an adverse drug reaction, the service shall automatically generate a Yellow Card notification to the requisite authorities. The service shall automatically anonymise and collate all adverse drug events and present them as a single data base to patient safety staff at unit, SHA and national levels. It should generate routine reports and trends over time automatically and support ad hoc reports at the request of authorised individuals. Repeat Prescriptions The service shall support repeat prescribing. The re-order list shall be printable, without needing to issue a prescription, for patients who mislay their list. Repeat prescriptions shall be authorized for: (a) a number of issues; or (b) until a review date, and these options to be user-settable. When a repeat prescription is issued on an FP10 form, a list of currently authorised repeat prescriptions and other appropriate details shall be printed for the patient to re-order. When issuing an authorised repeat prescription, the user shall be warned if prescriptions are being requested too frequently or too infrequently. The system shall print automatically patient specific messages on the re-order form, generated by rules. This would include reminders to attend for medication review, for blood tests required for drug monitoring, and for follow-up appointments at specific Primary Care clinics.
Required Response
113.8.17
113.8.18
113.9 113.9.1 113.9.2
The bidder must describe how it would support repeat prescribing.
113.9.3
113.9.4
113.9.5
113.9.6
FINAL 1.0a
Page 190 of 607
ICRS
Requirement 113.10 113.10.1 Controlled Drugs If a controlled drug is prescribed for a GP patient or an out-patient, a warning shall state that the drug is a controlled drug and that a hand-written prescription shall be produced. While handwritten controlled drug requirements continue to be needed under the misuse of drug regulations, the prescribing, ordering and supply of controlled drugs must comply with current legislative requirements and good practice guidance. Inpatient drug charts are not prescriptions but orders to administer and the regulations do not apply. 113.11 113.11.1 Decision Support The service shall automatically perform clinical checking at the point of prescribing, based upon agreed third party clinical data, local formulary and local rules. For those local formulary and local rules, the service shall allow the entry, amendment and deletion of data. The prescriber shall be alerted to any conflicts and all over-rides documented on the system with reasons (see Module 112). All checking and over-rides shall be auditable. Dispensing and Managing Medicinal Products Stocks of
Required Response
Each bidder shall describe how its solution deals with controlled drugs.
113.10.2
113.12
113.12.1
The service shall support dispensing - the validated provision and distribution of medicinal products, based on a validated prescription or order.
FINAL 1.0a
Page 191 of 607
ICRS
Requirement 113.12.2 The service shall support and seamlessly interact with all those processes involved in maintaining and managing control, manufacture and provision of medicinal products. This will include, but will not be limited by, the functions of: receipt / issue of batches of medicinal products across an integrated supply network; product costing / pricing / payments (in and out) interface to finance; store maintenance with distributed stock holding. To allow holding of patients own drugs; purchase Order / requisition maintenance and distribution; manufacturing including extemporaneous preparation and re-packaging; labelling; returns to stock & suppliers; stock checking, valuation and reporting; maintain trader / customer information; maintenance of all relevant classifications and reference files; and maintenance and reconciliation of received and issued credit notes. Medicines Administration Pharmacies shall be able to access the prescribing and drug administration facilities. There shall be a facility to add comments to a prescription including interventions. These shall be brought to the attention of the prescriber and administrator if indicated. There shall be a facility to add, with appropriate authority, clinical pharmacy notes. There shall be a facility to add a pharmacy warning to the patient master file, such that it is brought to the attention of the admitting nurse and prescriber. It shall be possible for a pharmacist to amend a prescription, or to review, validate, annotate, suspend or stop all prescriptions. This amendment shall require verification as nationally and/or locally determined.
Required Response
113.13 113.13.1
Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement.
113.13.2
113.13.3
113.13.4
113.13.5
FINAL 1.0a
Page 192 of 607
ICRS
Requirement 113.13.6 The service shall allow the recording of pharmacist clinical interventions documentation. Electronic prescribing functions shall be integrated / interfaced with the dispensing and stock management. All administration transactions shall recorded in real time and be auditable. be
113.13.7
113.13.8
Each bidder shall indicate how it would meet this requirement. Each bidder shall describe how the solution meets the needs to manage and record drug administration.
113.13.9
The service shall provide patient, department and ward-based drug administration records.
113.13.10
The service shall display the medications to be administered, filtered and sorted by user definable criteria, including patient name, location, and route of administration. The service shall allow real-time noting and verification that medication has or has not been administered. This facility shall be comprehensive and Include batch numbers, routes utilised where appropriate and predefined reasons for non-administration. There shall be a facility to record whether or not a patient is using their own drugs, so as to avoid an order being sent to pharmacy. This facility shall be able to be switched off in the event of the patient's own drugs running out. The service shall provide the facility to record the administration of drugs brought in by the patient on admission. These shall be clearly marked as such on the electronic prescription and medication record. The service shall facilitate the documentation of the patients ability to self-medicate. The service shall provide a facility for the patient or their carer/parent/guardian to record their acceptance of responsibility for administering medications. The service shall provide a facility to record that a drug is being administered by a patients carer/parent/guardian. Each bidder shall describe how the solution supports the administration of patients own drugs during hospital stays.
113.13.11
113.13.12
113.13.13
113.13.14
113.13.15
FINAL 1.0a
Page 193 of 607
ICRS
Requirement 113.13.16 The service shall be able to group patients by multi-disciplinary team, prescriber and/or ward for the purposes of drug administration. Drug rounds in hospitals shall be supported by providing appropriate advice / documentation; i.e., lists of which drugs shall be administered to which patients and at which times (on paper or on screen). The service shall allow on-line recording of administration on a per patient or ward location basis. The service shall be able to allocate patients to teams and locations; e.g., bays, as well as wards, and consultant for ease of administration. The service shall provide the option to be able to record the effect of a drug (positive and adverse effects) from a user-definable list. The service shall allow this to be retrospectively charted. Prescribing systems shall also permit recording of drugs administration both by prospective prescription and by post hoc. Medicine administration records shall be capable of being charted alongside other scheduled records (e.g., body temperature, blood pressure or test results). The service shall cover all drugs administered.
113.13.17
113.13.18
113.13.19
113.13.20
113.13.21
113.13.22
113.13.23
Each bidder shall describe how the solution covers recording administration of various drugs/methods of administration. Each bidder shall describe any innovative technology which may be employed for the validation of the patients identity, followed by the correct identification of the drug prior to administration; e.g., using barcoded patient wrist straps and barcoded medication labels which identify, not only the drug, but also the patient to whom it will be administered.
113.13.24
Correct patient identification prior to administration is of major importance. The service shall include facilities to support correct patient identification.
FINAL 1.0a
Page 194 of 607
ICRS
Requirement 113.13.25 The service shall be able to produce drug administration round listings. The administration report shall be available in printed form as well as on-line. The service shall be able to have user-defined drug round times by ward or part ward. For certain diagnoses the drug prescription details shall be checked against the dose and pathology data at the point of administration; i.e., near patient testing (e.g., testing glucose levels). The system shall highlight drugs that need to be given by doctors, specialist nurses or other Clinicians. The service shall record the reasons for nonadministration, with the reasons selected from a pre-defined list. The service shall provide a switchable option to allow a double digital signature upon administration of, for example, controlled drugs, IVF and blood This facility shall be switchable, based upon the ward or by location on a ward. The service shall allow for the use of patients own drugs. The service shall allow for the administration of short leave drugs; e.g., less than one day. The service shall also allow for the ability to turn off admin for patients on leave. 113.13.34 The service shall provide comprehensive variance monitoring and reporting; both on-line during care and during post-care review and evaluation. The service shall allow once-only documentation of drugs that have not been prescribed before being administered.
Required Response Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement.
113.13.26
113.13.27
113.13.28
113.13.29
113.13.30
113.13.31
Indicate how this will be achieved.
113.13.32
113.13.33
113.13.35
FINAL 1.0a
Page 195 of 607
ICRS
Requirement 113.13.36 The service shall allow the prescriber to be able to specify the time of administration as a specific time or as a relative time in relation to other drug or non-drug orders. The alert or prompt for administration shall be deployed when an administration record of the reference drug or order is made. The service shall allow the administration of part vials or ampoules to be recorded. The service shall allow the recording of spilled, lost and wasted drugs and breakages. The service shall identify those drugs to be administered that require reconstitution and/or dilution before use and provide information to the administering practitioner concerning appropriate quantities and diluents to use. Mechanisms shall be in place to reduce the risk of administration error. For example the use of bar-coding. Real-Time Monitors The system shall provide support for real time monitors delivering drug treatments. Administration Report Administrations should still be possible, even if the on-line system is unavailable due to hardware limitations; e.g., lack of mobile equipment. Chemotherapy
113.13.37
Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement. Each bidder shall indicate how it would meet this requirement.
113.13.38
113.13.39
113.14 113.14.1
113.15 113.15.1
113.16
FINAL 1.0a
Page 196 of 607
ICRS
Requirement 113.16.1 This is referring to work performed in the main by radiology/oncology/haematology services for protocol driven chemotherapy, which may be then aseptically prepared in pharmacy. Whilst not all of it is protocol-driven, it is expected that a protocol of one form or another would govern the core of the work. A protocol, in this context, is a template for therapy. This is a specialist area with many requirements for data collection from local specialised databases to individual patient profiles. The key to this process lies in the protocol, in that, by the time to prescribe, all the work has been done, to a greater extent, in drawing up/constructing the protocol. It is important to bear in mind that, once a treatment protocol is decided upon and the patient details inputted, the protocol translates into a treatment plan or schedule from which prescription is generated for items to be aseptically prepared/dispensed. The scheduler therefore becomes the pivotal link between the clinical and the preparation and administration sections of an integrated system. 113.16.2 The service shall support total parenteral nutrition regimens.
Required Response Bidders should respond to this with details of either functionality available or how an interface will be constructed to provide the benefits of integration. Where such an interface exists, the bidder must give examples of how such an interface has previously been successfully implemented.
FINAL 1.0a
Page 197 of 607
ICRS
114 - Diagnostic and Investigative Services Overview Diagnostic and investigative services, such as pathology, radiology, audiology, cardiology, pulmonary function, neurophysiology, etc., receive orders/requests (see Module 110) and return/distribute results (see Module 111). These services also have internal functions that can be supported by ICRS functions. Some of these will include scheduling functions described elsewhere (see Module 113). Results may be generated by electronic systems (e.g., chemical analysers) or be provided manually (e.g., a radiologists opinion, dictated and typed), or by a combination of both. This module describes the functions required in these departments. The pathology modernisation programme is moving pathology services away from individual hospitals towards managed clinical networks usually at SHA level. Also, increasingly common tests will be provided by near patient or ward / practice testing kits which will be electronically surveilled by the pathology service. This module will be relevant where diagnosis and treatment centres are established. Scope Components Some of the elements will vary for each service. Two, pathology and radiology, have been detailed in this section, but they are to be regarded as examples for other departments. Pathology Defining the order/result. Work outside the laboratory. Inbound patient/sample booking/reception. Request entry. Management of sample throughput/ worksheets. Reporting of tests data entry. Classification of examinations. Validation/authorisation. Incomplete work. Enquiry. Storage, dispatch and retrieval of test reports. Departmental management information. Specimen/tissue identity. Quality control and statistics.
FINAL 1.0a
Page 198 of 607
ICRS
Specific departments/disciplines. Histopathology and non-gynaecological clinical cytology. Mortuary-specific. Medical microbiology and infection control. Bacteriology. Anti-coagulation. Surveillance and quality assurance of out of department analysers.
Radiology Inbound patient/sample booking/reception. Management of patient throughput. Reporting of radiology examinations. Ultrasound. Classification of examinations. Storage, dispatch and retrieval of examination reports. X-ray film library management.
Assumptions The results facilities within the ICRS service may need to integrate with existing/legacy departmental systems, such as pathology and radiology, which may be located at different sites within the health economy. Some parts of the health economy may wish to pursue the implementation of new functionality within ICRS that generates results.
Benefits and Outcomes To: Patient Improved process and outcomes for patients/clients. Reduced turn-around time for test results; and important results known sooner. Reduced number of re-tests, as results can be found even if the paper record is missing. Clinician Clinicians/carers have clearer view of agreed patient/client care plan as they can see the results that have led to chosen plan/action e.g., fracture from X-ray or high lipid from blood test. Improvement in quality of results completeness and possibly clarity (coding).
FINAL 1.0a
Page 199 of 607
ICRS
No need to transcribe between Primary Care, Secondary Care, mental health and Social Care. Reduced turn-around time for test results; and important results are known sooner. Reduced time searching for patient information by health professionals. Reduces unnecessary retesting. Manager
Optimisation of resource time within and across settings.
Scenario - Blood test (a) Managing Joans Chronic Illness and Leg Ulcers The pathology lab receives an order set for a selection of blood tests. The lab supervisor reviews the order and authorises it. On receipt of a blood sample, the supervisor locates the associated order (e.g., using a barcoded label) and schedules the tests. The requestor is alerted that the sample has been received and the tests are scheduled. A lab technician carries out the tests using an automated test system, which uploads the results. A set of report templates is selected, based on the order set, and the report is populated from order data and the uploaded results, together with normal ranges from decision support. Abnormal results are highlighted. The requestor is alerted that unverified results are available. The unverified report is routed to the lab supervisor, who validates the data, makes some annotations, and authorises the report. If there is a problem with the result, an alert is sent to the requestor; e.g., by SMS text because of urgency indicated by the result, and it is copied to others. The report is routed to the originator, who, having received the alert by pager, logs in at a nearby terminal and reads the report.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Integration of existing products from Module 770 - Clinical Communications, so that existing results are available much more widely; some order communications included. Minimum Level to Be Achieved by December 2006 (Phase 2) Target is for all other types of results and reports from diagnostic services with direct links from clinical equipment to be provided, with images being provided by PACS. Target for 2010 Services for diagnostic and investigative services departments will form a fully-integrated element of the integrated service. Overview Requirements
FINAL 1.0a
Page 200 of 607
ICRS
Requirement 114.1 Overview Results will be reported, and alerts raised, using standards defined in Module 770 - Clinical Communications. Use of NHS Number to identify patient in results is required wherever possible. 114.2 Benefits and Outcomes The service shall deliver the benefits described above. 114.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP.
Required Response Each bidder shall describe its approach to providing support for diagnostic and investigative services departments. Each bidder shall describe its approach to legacy applications for these service areas.
Each bidder shall describe how it would deliver the benefits and outcomes from this module.
114.4
114.5 114.5.1
Pathology The following specification has been developed in the light of current laboratory medicine service configurations. The current service configuration is under review, and new guidance for service delivery will be published by the Department of Health in the second half of this year. It is possible that with the rapid development of analytical and information technology, the type of LIS system currently in use in most laboratories will not will not be capable of supporting pathology networks and the necessary exchange of information across them. Much of the functionality previously contained within the laboratory systems for the chemistry / haematology disciplines can now be provided by the standard interfaces supplied by diagnostic companies with their instruments. Future lab systems for the numerical disciplines will probably consist of a generic database with functionality attached in the form of Each bidder shall describe their proposed solution for pathology requirements.
FINAL 1.0a
Page 201 of 607
ICRS
Requirement instrument interfaces with self contained, QA packages, inventory control and audit facilities which are requirements of clinical pathology. The use of data mining tools will enable the conversion of the contents of the generic database into information and knowledge. It is anticipated that guidance will be issued by SHAs during 2003 with respect to the future organisation of laboratory medicine services following the publication of the DoH guidance. The service delivery model may be reevaluated in the light of this guidance. 114.6 114.6.1 General The service shall support point of care testing (e.g. ITU) in terms of results capture, monitoring for quality assurance and analyser maintenance. This shall include the operator identity of the person that performed the test and the reagent use. The service shall provide the ability for local trust systems administrators to add new tests and to modify test details such as reference ranges and units; codes applied to tests and age or age/sex dependant ranges. It shall be possible to examine the history of how tests were set up at any point in time. Date, time and user stamping of changes shall be supported (see also generic functionality on audit trails). The service shall record the reference range with the result as part of the historic record. This shall remain the case on the core record. It shall be possible to define the normal range for the test as either test specific or patient specific. The service shall have a specimen tracking application to facilitate the storage and retrieval of laboratory samples. The service shall provide a facility for the order number to accompany the
Required Response
Each bidder shall indicate how this will be achieved.
114.6.2
114.6.3
114.6.4
114.6.5
FINAL 1.0a
Page 202 of 607
ICRS
Requirement request. 114.6.6 The service shall support sample management for send-away work with the following functionality: 114.6.7 print a request form to accompany the sample; and tests on a request for one specific destination on a single form.
Required Response
The service shall provide the means of recording the date sent, i.e. status of request. The service shall record information such as destination, address and telephone number for each test referred. The service shall provide the facility to review referred work outstanding for a particular time period. The service shall record the result for that test and print the result in an integrated report with other work done on that request, identifying the name of the laboratory that conducted the test. The service shall provide the facility for results to be entered manually or electronically from the laboratory to which the request was referred. The service shall provide a costing system at test and investigation level for costing, service level agreement and other financial reporting. The service shall provide the facility to scan and store images, or pointers to images, in the Patient Record, and to use them in reports as required. The service shall provide the facility to create an on-line reference manual/teaching aid of imported images of pathological specimens. Request Entry The service shall support a secure, paperless phlebotomy service. It shall
114.6.8
114.6.9
114.6.10
114.6.11
114.6.12
114.6.13
114.6.14
114.7 114.7.1
FINAL 1.0a
Page 203 of 607
ICRS
Requirement have the facility to produce fully flexible, user definable phlebotomy lists and associated bar-coded sample labels.
Required Response
114.7.2
The service shall have the facility to manage uncollected or unreceived samples. The service shall set rule bases to either keep or remove a request form image. It may be necessary to keep this image even when the specimen is archived. System generated patient numbers within a user defined number range shall be supported by the service. Patients shall first be registered on the community master patient index. System generated numbers may also be used in conjunction with the patients NHS Number. These will be used for patients currently not registered on the system and who have no hospital number available. The service shall provide the ability to review previous results or requests at request entry in order to eliminate unnecessary requesting. The service shall support the storage of patient name, patient date of birth, NHS Number, report destination, consultant, clinical speciality and requesting clinician w the request in order that ith future changes to these data items will have no impact on historical data. The service shall have the facility to flag certain types of patients e.g. high-risk, staff and VIP, with the display of the flag as appropriate. When patients flagged as high risk are processed on the service, it shall alert the user of a potential risk. The service shall provide a facility to flag a patient of interest, so that the next time the patient presents, the user, or other nominated personnel, who
Each bidder shall explain how their proposed system handles the management of uncollected samples.
114.7.3
114.7.4
114.7.5
114.7.6
114.7.7
Each bidder shall provide details of how this is achieved.
114.7.8
114.7.9
FINAL 1.0a
Page 204 of 607
ICRS
Requirement flagged the patient will be automatically notified via e.g. e-mail, voicemail or pager. 114.7.10 The service shall provide a facility to specify the collection date and collection time and received date and received time of specimens and support the use of user-defined macros to facilitate this. This shall include start and finish times for e.g. urine collections etc. The date and time of collection, (which may include use of am or pm), shall be used for logical chronological display of records. The service shall support a scaling system for request priority.
Required Response
114.7.11
Bidders are required to indicate how this and specific instructions will be flagged to the staff performing the analyses.
114.7.12
The service shall specify the category of the request, i.e. NHS or private, and include appropriate billing codes or flags. The service shall provide the ability for users to allocate internal sample / specimen numbers on receipt of sample and to adjust them manually for all requests including electronic. The service shall support a sample / specimen numbering format which is configurable with the multiple numbering systems available for each pathology discipline. Laboratory numbers (request numbers) may be used to identify specimens. The service shall be capable of allocating sample number ranges to different departments and work areas. The service shall support the format of laboratory numbers being user definable for each site. The service shall provide the ability to add further work and results to an authorised specimen. The service shall support automatic conversions to uppercase, and perhaps
114.7.13
114.7.14
114.7.15
114.7.16
114.7.17
FINAL 1.0a
Page 205 of 607
ICRS
Requirement sentence-case, where appropriate. 114.7.18 The service shall facilitate the handling of non-patient specimens e.g. environmental, with appropriate use of user-configurable tests and report formats. The service shall allow direct branching from the request entry module to the result entry module for those tests that require the addition of results at the time of booking in. The service shall allow direct branching from result entry and authorisation functionality to request entry process. The service shall allow the entry of free text on a request and enable this to be available on the report. The service shall provide the facility to automatically print bar code sample labels (including size of labels) and other modalities directly from the host system at the time of ordering and at any other time. The service shall be able to store admission diagnosis and relevant clinical information on a sample basis. The service shall support the linking of patients into family groups, for example, but not limited to, haemoglobinopathy. The service shall allow the sequential block book and report for a series of specimens requiring the same test(s) on different patients. The service shall support the use of Dynamic Functions Tests (DFTs) comprising a series of timed specimens, each requiring one or more tests, from an individual patient before and following a challenge, for example, but not limited to, short synacthen test, insulin tolerance test and combined pituitary function test.
Required Response
114.7.19
114.7.20
114.7.21
114.7.22
Each bidder shall state how they propose to do this.
114.7.23
114.7.24
114.7.25
114.7.26
FINAL 1.0a
Page 206 of 607
ICRS
Requirement 114.7.27 The service shall provide the facility to book a series of specimens as a DFT at request entry or retrospectively build previously booked specimens into a DFT. It shall be possible to add additional specimens to a previously booked or built DFT. The service shall allow separate independent recording of both 24-hour clock specimen collection time and offset time (time relative to the challenge e.g. 15 minutes prechallenge, 30 minutes post-challenge etc.) for each specimen that forms part of a DFT. It shall be possible to enter and report specimens in their correct sequence, even if numerical collection or offset times are not available, for example, b reporting as just pre- and y post- challenge results. The service shall provide DFT reports which are fully user-formatable and allow reporting of type of DFT, clock times, offset times, test headings and results. It shall be possible to add and report user-generated coded or free-text comments for individual specimens or the complete DFT. The service shall support the rapid entry of multiple samples from the same patient e.g. multiple swabs from the same patient. The service shall support the generation of an incident log and the rapid entry of patients from the same location or incident. Worksheets The service shall support the automatic generation of worksheets at any point including request entry and results entry for user defined work areas. The service shall allow for the defining and printing of user-configurable worksheets including layout and content.
Required Response
114.7.28
114.7.29
114.7.30
114.7.31
114.8 114.8.1
114.8.2
FINAL 1.0a
Page 207 of 607
ICRS
Requirement 114.8.3 The service shall allow the user full control of specimens to be added, removed or edited from a worksheet. The service shall allow specific cup positions on worksheets to be assigned for quality control specimens and to include void positions. The service shall including previous worksheet. Data Entry The service shall support the attachment of images (such as digital camera outputs) to the Patient Record and reports, either as an integral part of the EPR or as a link to a Trust PACS system. The ability to enter results (via interface, etc.) before the request is ordered shall be available where analysers have set parameters. Real-time, uni, and bi-directional, host query and queuing (auto send) interfaces shall be supported for instruments connected directly to the host or through an interface engine. The service shall allow result entry in both single and batch modes. The service shall allow result entry in worksheet mode. The service shall allow result entry from multi-specimen modalities e.g. multipoint agar plates and microtitre wells. The service shall allow userconfigurable tabular result entry e.g. organism/antibiotic combinations and Haematology differential cell counts. Haematology differential allow access to current FBC/differentials and all well as the Full Blood screens shall and previous comments as Count (FBC) be capable results on of a
Required Response
114.8.4
114.8.5
114.9 114.9.1
114.9.2
114.9.3
114.9.4
114.9.5
114.9.6
114.9.7
114.9.8
FINAL 1.0a
Page 208 of 607
ICRS
Requirement analyser scattergrams/flags. This shall apply to all analysers. 114.9.9 The service shall support repeat or loop result entry for similar investigations/specimen types. The service shall automatically calculate results based on the values of other tests, with support for various arithmetic operations. The service shall be able to use patient details, such as age, to calculate the result. The service shall be able to use the results of a test from one discipline in the derivation of a parameter in another discipline. The service shall support: reference and panic ranges being available which relate to, without limitation, age, gender, pregnancy, phase of menstrual cycle, pre and post-menopausal etc. diagnosisand location-related ranges being available for use in auto-authorisation. analysis method reference ranges being available.
Required Response
114.9.10
114.9.11
114.9.12
114.9.13
114.9.14
The service shall automatically flag results outside both the reference and panic ranges. The service shall ensure that the flags referred to in 113.9.14 are included in pathology EDI messages. The service shall support user definable delta checking of results (see also Quality Control section 114.14). The service shall allow direct branching or access from request entry, result entry and authorisation modules to enquiry modules. The service shall support the automatic generation of further work if userconfigurable rules base conditions are
114.9.15
114.9.16
114.9.17
114.9.18
FINAL 1.0a
Page 209 of 607
ICRS
Requirement satisfied at result entry. It shall be able to flag up to the requestor, laboratory requested repeat specimens. 114.9.19 The service shall support listing of results outside user specified panic limits. Validation/Authorisation The service shall support multiple levels of technical and clinical verification. The service shall ensure that it is possible to check results against a series of user-defined rules for validity prior to technical release. The user shall be alerted of results that do not comply with the rules. The service shall ensure that results entered shall be checked against a series of user-defined rules for clinical validity prior to clinical release. The user shall be alerted of results that do not comply with the rules. The service shall support automatic verification according to user-defined rules. The service shall support automatic authorisation according to user-defined rules. These rules shall be definable for different periods of the day, e.g. out of hours. It shall be possible to review specimens that have been authorised by this system e.g. out of hours (ghost results in the present system). The service shall provide the facility for results to be manually technically verified or clinically authorised; results shall be presented to the user automatically in a flexible user-defined order e.g. sample number, sample type, date, with the option of altering the presentation of the queue at the time of authorisation.
Required Response
Each bidder shall state how this would work and what prompts would be in place.
114.10 114.10.1
114.10.2
114.10.3
114.10.4
114.10.5
114.10.6
114.10.7
FINAL 1.0a
Page 210 of 607
ICRS
Requirement 114.10.8 The service shall have flexible results review e.g. sample type, sample number, and patient, batch with previous results. The service shall give access to FBC analyser scattergrams/flags/plots at all validation and authorisation stages. The service shall provide the facility to retrace through the authorisation queue or go directly to a specific report. The service shall have user-defined rules to prevent the use of inappropriate comments on user specified tests. The service shall support rule-based automatic addition of coded and userdefined free-text comments to reports. Multiple authorisation queues or workflow concepts shall be available in the solution so that results to be authorised can be assigned to appropriate review queues according to user-defined rules. The service shall provide the ability to refer a result, and attach an associated non-reportable note, to another user. The service shall support single sign-on and single patient focus so that when verifying or authorising results, the patients previous results can be displayed with rapid navigation between windows. All windows shall be refreshed together. The service shall support HL7 design standards for instant result retrieval from other compliant applications. The service shall allow a non-reportable back-of card or Notepad free text or coded comment to be added to any test result at the verification or authorisation stage. It will be necessary to ensure the information contained within this notepad is structured and fully searchable.
Required Response
114.10.9
114.10.10
114.10.11
114.10.12
114.10.13
114.10.14
114.10.15
114.10.16
114.10.17
Each bidder shall state how this is to work.
FINAL 1.0a
Page 211 of 607
ICRS
Requirement 114.10.18 The patient and specimen notepad facility shall provide the means to hold additional information not easily communicated elsewhere within the system. The notepad facility shall be accessible within the system irrespective of the current location within the application. The service shall support all Office functions for the manipulation of textbased elements of reports. The service shall provide the facility to export word-processed reports in a portable format, e.g. RTF, if required outside of the database. The service shall allow subsequent editing of coded comments. When reviewing results the service shall display reference ranges. Clinical data shall be displayed on screen at the verification stage, with the option to view the scanned request form. The service shall display clinical data on screen at the authorisation stage. The service shall allow investigations to be returned to the work pool with an appropriate non-reportable explanatory text comment or flag to denote reasoning. The service shall allow users to hold specimens on authorisation queues/lists with suitable explanations recorded to prevent unauthorised release. The service shall provide time warnings for held specimens to prevent unreasonable delay. The service shall allow batch verification of a user specified range of sample numbers/tests. The service shall allow a reportable coded or free text comment to be added easily to:
Required Response
114.10.19
114.10.20
114.10.21
114.10.22
114.10.23
114.10.24
114.10.25
114.10.26
114.10.27
114.10.28
FINAL 1.0a
Page 212 of 607
ICRS
Requirement 114.10.29 Any test result at the verification stage. Any test result at the authorisation stage.
Required Response
The service shall support a privilegelevel controlled facility for editing and amending authorised results, with an ability to re-authorise and re-issue the result. Incomplete Work The service shall include the facility to list incomplete work by department/work area/test/consultant (and other userdefined criteria). The service shall include the facility to list work not done within a user specified turnaround time. The service shall include the ability to monitor and audit the progress of specimens/investigations through various stages in the laboratory. This shall be available to any enquirer. If appropriate, the service shall prevent release of current results if outstanding investigations are still to be performed on a specimen. The service shall provide the ability to run statistical reports on active and incomplete requests. Enquiry The service shall allow flexible access to enquiry modules including via the laboratory specimen number. The service shall provide operational patient lookup requirements. The service shall provide the ability to seamlessly link a patients results which may be stored in separate records using different numbering systems, so that result retrieval pathways display results on all linked numbers when accessing any single number. Each bidder shall give details of the fields which can be used for enquiry.
114.11 114.11.1
114.11.2
114.11.3
114.11.4
114.11.5
114.12 114.12.1
114.12.2
114.12.3
FINAL 1.0a
Page 213 of 607
ICRS
Requirement 114.12.4 The service shall allow users apply user-definable filters to restrict the display of results by sex, specific location, test code etc. The service shall support the display of results in various user-defined orders e.g. chronological and reverse chronological etc. The service shall provide the facility to easily page forward and back when viewing results without re-entry of search criteria. It shall be possible to display all results for a specimen on a single screen without scrolling (subject to maximum number of tests). The service shall provide the facility to highlight positive or abnormal results following an applied search. Negative results should be highlighted e.g. titres after immunisation. The service shall support automatic logging of telephone transactions. This information shall be available within an audit trail. The service shall ensure that it is possible to suppress sensitive results from view in enquiry screens except to users with the appropriate access level. The service shall provide the ability to graph a test or a group of tests on screen and hard copy according to user-defined criteria. All enquiry screens within the service shall show the user the current status of the specimen e.g. awaiting receipt, received but not analysed, awaiting authorisation etc. Transfusion enquiry screens within the service shall show number of units requested and their unit numbers and current number of unit still available for transfusion. Specimen/Tissue Identity
Required Response
114.12.5
114.12.6
114.12.7
114.12.8
Each bidder shall provide details about how their proposed system meets this requirement.
114.12.9
114.12.10
114.12.11
114.12.12
114.13
FINAL 1.0a
Page 214 of 607
ICRS
Requirement 114.13.1 The service shall provide functions for the identification of tissues and specimens. The service shall provide the facility to flag high-risk specimens and to generate appropriate warnings on documentation. It shall be possible to attach risk status to either patients or samples and for risk status to be active for the life of the patient or a time period defined by the user. Risk status to be identifiable either by a single discipline or pathology wide. The service shall enable specimens to be described using national coding systems e.g. SNOMED CT, READ. Other additional descriptive data may be included, e.g. collection procedure, period and volume of collection, anatomical origin, free text comment. For applications where location is important hierarchical description available. anatomical a coded shall be
Required Response Each bidder shall state which formats are available and any restrictions on Specimen Number format.
114.13.2
114.13.2
114.13.3
Each bidder shall state the facilities for Specimen Type to be coded, and to add a sample comment, coded and/or free text.
114.13.4
The service shall enable the relationship of specimens e.g. dilutions, the original tissue that a block is from, to be identified. The service shall support the recording of where specimens are stored and how and when disposed of. More than one storage location may be defined per pathology specialty/laboratory. The service shall be able to prompt, based on local rules, where the specimen shall go next at any stage. Quality Control And Statistics The service shall support a variety of external quality assurance schemes. Electronic input and output shall be available to various schemes. The management of quality control data files shall be dependent upon user Each bidder shall supply information on any facilities that the system has for handling this data.
115.13.5
114.13.6
114.14 114.14.1
114.14.2
FINAL 1.0a
Page 215 of 607
ICRS
Requirement access and privilege levels. 114.14.3 The service shall support quality control functions shall be based upon test codes, which shall be user definable. The service shall support each quality control entry or alteration of a file shall be automatically tagged by the operator ID and be recorded in the audit trail. There shall be options to specify quality control material, manufacturer, lot number and expiry information, with the operator being prompted prior to material expiry. The service shall provide the facility to make reagent lots and calibration data available for QA scheme results. The service shall support the following: Graphical quality control representation shall include levy jennings, youden plots, cusum plots (double level); Graphical quality control representations shall be in colour, with the ability to display and print up to 3 levels of quality control simultaneously; The configuration and use of westgard rules; and Levy -jennings plots shall include daily means, plus daily result scatter and be based on 3SD limits either side of mean.
Required Response
114.14.4
114.14.5
114.14.6
114.14.7
114.14.8
All plot options shall also include options to plot all results, the previous calendar month results or within userdefined date intervals. It shall provide a symbolic (e.g. icon) indication of quality control results, i.e. single results, single results outside +/1SD, +/- 2SD, all results outside 3SD, daily means or excessive drift or scatter. The service shall be able to summarise performance data against target limits.
114.14.9
114.14.10
FINAL 1.0a
Page 216 of 607
ICRS
Requirement 114.14.11 The service shall be capable of providing daily, monthly patient means. The service shall have the facility to calculate the mean and standard deviation of any test over a user defined date range. The service shall support median and range calculations. The service shall have the facility to plot one result against another. The ability to upload quality control data from analysers (assuming the analyser supports this) to the host system is desirable. Histopathology & Non Gynaecological Clinical Cytology The service shall retain the data for histopathology & clinical cytology for a user-defined period. The service shall support histology, cervical cytology, non-gynaecological cytology, autopsy, immunology and semenology. The service shall provide a comprehensive search tool for histopathology and clinical cytology cases that will select cases by various user-specified parameters and also allow retrieval from other data sources. From the cases selected by the search, it shall be possible to design and print reports that will list the cases, group cases by type, calculate totals, etc. The service shall display the information generated by each search on screen with an option available to print it or generate reports that will list e.g. the cases, group cases by type, calculate totals, etc. The service shall extract data on histopathology and clinical cytology cases in a user definable format as a flat file or export to an external PC application or via direct query of the
Required Response
114.14.12
114.14.13
114.14.14
114.15
114.15.1
114.15.2
114.15.3
114.15.4
114.15.5
FINAL 1.0a
Page 217 of 607
ICRS
Requirement database. 114.15.6 The service shall conform to the current NHS requirements for bi-directional messaging with health authorities Exeter systems for Cervical Cytology Screening. When signing histopathology and clinical cytology cases out, the reporting pathologist shall be automatically prompted with their own cases ready for signout, in a user-defined order. The service shall provide a batch signout facility which will allow the reporting pathologist to signout a user specified range of cases in one procedure. The service shall enable single, user-specified cases to be signed out. The service shall allow user-defined time limits to be set after which consultant staff are presented with a list of their cases requiring "signing-out. The service shall support barcode sample management for tracking signed-out and transferred cases. The service shall comply with the British Society For Clinical Cytology (BSCC) document Requirements for the Cytopathology Component of a Laboratory Computer System, the Pritchard Report and the BSCCs Recommended Code of Practice for Laboratories providing a Cytopathology Service 1997. The service shall have the facility to record against individual specimens or tissues that consent has or has not been given for the use of these tissues for research or other purposes. The service shall have the facility to incorporate diagrams, photographs, etc., with a library of routinely used diagrams. If the images cannot be stored within it, links to an external
Required Response
114.15.7
114.15.8
114.15.9
114.15.10
114.15.11
114.15.12
114.15.13
114.15.14
FINAL 1.0a
Page 218 of 607
ICRS
Requirement images database shall be supported. 114.16 114.16.1 Cytology The service shall support the use of the BSCC terminology for the reporting of cervical cytology specimens as specified by the NHS Cervical Screening Programme (NHSCSP). The service shall support the use of pro-forma based reporting that reflects the use of the Royal College of Pathologists minimum data set and the national cancer minimum data sets. The service shall provide the facility to monitor individual screener and pathologist statistics and reporting profiles. The service shall have the ability of defining the identity of the smear taker as well as other patient ID. The service shall provide a integrated n cytology smear recall system for inadequate as well as abnormal (borderline or above) smears. A user defined maximum or minimum number of reminder recall letters, at userdefined intervals, is required. The service shall be able to link cytology (non-gynaecology and cervical) samples with histology biopsy samples for audit purposes. The service shall ensure that it is possible to log multiple provisional reports and screener when proc essing a smear. The service shall provide a nonreportable notepad or back-of-card facility to record information such as why a smear is being referred to another screener. The service shall support the receipt of temporary indexes from PCT calls for cytology screening to aid request entry.
Required Response
114.16.2
114.16.3
114.16.4
114.16.5
114.16.6
114.16.7
114.16.8
114.16.9
FINAL 1.0a
Page 219 of 607
ICRS
Requirement 114.16.10 The service shall have the ability to flag specific patients to tie up with Histology and to flag LLETZ biopsy patients to give a copy report to the Colposcopy Department. The service shall support every entry field being able to have a default setting on type of specimen. Where required, i.e. all gynaecological entries shall automatically default to Female sex. The service shall provide a choice between single or multi-entry facilities, i.e. machine generated or selfgenerated pre-selected numbers. The service shall have the ability to scan in and integrate within the History Screens the results of any outside referred reports attach/scan in referral letters. Gynaecological cytology shall have the ability to interrogate the service and produce data regarding the length of normal re-call on a patient (3 year or 5 year re-calls). The service shall generate different user-defined recall letters to patients once a pre-determined time interval recall period has elapsed. The recall period shall be able to be amended independently of specimen receipt and shall allow a patient comment to be added so that the reason for amendment can be recorded. The service shall support searches by specific department number only, e.g. 12345. Previous years will require specific year format added e.g. 9912345. All previous abnormal reports shall have a specific flag visible when reporting. The service shall be able to transfer unreported names of patients to the Personal Data Spine to prevent the generation of recall letters.
Required Response
114.16.11
114.16.12
114.16.13
114.16.14
114.16.15
114.16.16
114.16.17
114.16.18
FINAL 1.0a
Page 220 of 607
ICRS
Requirement 114.16.19 In accordance with national guidelines the service shall support a failsafe system on all cervical smears that have an abnormal (i.e. non routine) recall. The service shall be able to supply a list of all cases that have not had subsequent treatment, histological, colposcopic or cytological within an agreed time following the advised action on the report. Reporting Reporting shall follow specific pathways, some of which are compulsory (e.g. RR following primary screening). There shall be the ability to step through the system to enable review of: 114.17.2 primary screening, second opinion, final consultant report; rapid review; and final report (checkers/consultants).
Required Response
114.16.20
114.17 114.17.1
The service shall be configured to allow the previous cytology and histology reports on the patient to be visible on screen, with the ability to apply filters such as case type, age, year, pathologist etc. during reporting. The service shall automatically generate a copy of the smear report for the patient's GP, as well as the sender, if the GP did not send the smear. The service shall provide the facility to import user defined text files into the report. All reports within the service shall have rapid review. A limited access, via security clearance, shall be allowed to change or update previously reported cases, Audit Trailed. The service shall support the constant availability of outstanding work lists for all levels of work.
114.17.3
114.17.4
114.17.5
114.17.6
114.17.7
FINAL 1.0a
Page 221 of 607
ICRS
Requirement 114.17.8 The service shall easily produce records of turn round times from receipt to reporting. The service shall restrict the automatic release to hospital-wide/SHA Primary Care practitioners of reports, until specifically released from the laboratory after the print run. Statistics The service shall be NHSCSP compliant and be automatically updated to any change in requirements. This will cover all individual performances whatever grade. The service shall ensure the following: PPVs are producible for any individual consultant as well as department based; PPVs are available in both reporting cytopathologist and histopathologist mode; KC61 national statistics are produced automatically on demand; PPVs are calculable over any specific period as a single entity as well as that demanded in the KC61; NHS colposcopy standards, as defined, can be produced; and recurring audit requirements are set up and run automatically, e.g. cervical invasive cancer audit run on a regular 3-month basis, i.e. SNOMED.
Required Response
114.17.9
114.18 114.18.1
114.18.2
114.19 114.19.1
Mortuary Specific The proposed service shall include a mortuary management module. The service shall provide for the recognition and potential separation of Hospital and coroners post mortems. The service shall provide for the registration of deceased patients and all relevant information. It shall include information about tissues and organs that might be retained and their
114.19.2
114.19.3
FINAL 1.0a
Page 222 of 607
ICRS
Requirement subsequent fate. 114.19.4 The service shall provide for the logging of information concerning the removal of deceased patients. This information shall be available for other users. The service shall support data capture for the following: 114.19.6 receipt of a body; record any valuables etc. received with the body; is a post mortem performed and if the post mortem is requested by the coroner or by the hospital; post-mortems on bodies received in the mortuary including full necropsy reporting; the storage of removed whole organs; disposal requirements; and the release of a body and the collecting undertaker.
Required Response
114.19.5
The service shall provide facilities to directly request histopathological examinations against specimens removed at post-mortem. The service shall have the same search facility for statistics and audit trail as the histology module. The mortuary management facility shall provide the following reports: report of hospital cases requiring post mortem; report of sudden deaths in the community; report of paediatric cases requiring post mortem; and report of histopathology performed on post mortems.
114.19.7
114.19.8
114.19.9
The service shall have a fully integrated patient history screen, covering all pathology disciplines. The service shall have the ability to attach user definable work units to individual steps.
114.19.10
FINAL 1.0a
Page 223 of 607
ICRS
Requirement 114.19.11 The service shall provide a facility to record and search for post-mortems that have been carried out at other mortuaries on behalf of the Trust.
Required Response
114.19.12
Medical Control
Microbiology
&
Infection
114.19.13
The service shall support the reporting of notifiable diseases to the local Communicable Diseases Surveillance Centre (CDSC). The service shall support the collection of PHLS work type statistics and generate PHLS work type returns. The service shall support an electronic link to other Trust laboratories including the regional public health laboratories for transmission of referred requests and automatic reporting. The service shall provide epidemiological and research reporting to allow extraction of data based on user-defined search criteria e.g. ward, consultant, GP and/or Practice, specimen type etc. These searches shall be available to users in real time without undue overhead of system time. The service shall provide real-time user definable flagging of epidemiological significant features via a rules base, together with an ability to provide adequate infection control information. The service shall provide postdischarge surveillance reporting of patients referred to general practice. The service shall support the requesting, results entry, validation, authorisation, enquiry and reporting of multiple samples from the same patient over time e.g. paired sera. The service shall support the expert system for antibiotic sensitivity testing, with easily updateable rules.
Each bidder shall state how the system will support this.
114.19.14
114.19.15
114.19.16
114.19.17
114.19.18
114.19.19
114.19.20
FINAL 1.0a
Page 224 of 607
ICRS
Requirement 114.19.21 The service shall allow continual surveillance of marker organisms such as MRSA and VRE. Bacteriology 114.19.22 Depending on the investigation requested the service shall allow the entry of additional patient, sample and clinical information including antibiotic therapy. The solution shall indicate patients with attached hazard warnings. The service shall allow investigations to be set up to be viewed under strict access controls. To allow the processing of outbreak investigations, the service shall link samples together as an outbreak and to enter multiple requests with the same specimen and requester information. To describe the specimen fully, the service shall provide the ability to record collection procedure and anatomical origin coded descriptions. The service shall allow the batch entry validation and authorisation of results. The service shall have an epidemiology search facility, or alternatively have comprehensive links to other commercially available packages in this field. Serology/ Transfusion The service shall allow pregnancy history and blood transfusion history to be recorded. The service shall automatically identify special patient groups and their requirements. The service shall support all bar codes used by the national blood authority, as detailed in the Specification for Uniform Labelling of Blood and Blood Products
Required Response
114.19.23
114.19.24
114.19.25
114.19.26
114.19.27
114.19.28
114.20 114.20.1
114.20.2
114.20.3
FINAL 1.0a
Page 225 of 607
ICRS
Requirement published by the NBTS and Scottish NBTS. The blood bank inventory shall accept stock from any regional blood transfusion or EU centre. 114.20.4 The service shall support the use of all Blood Transfusion Service ( BTS) blood product types. The service shall make it possible for users to configure the system to accept any new product type the BTS may issue. The service shall support a multi-site blood bank inventory. The service shall support full access to the inventory from any site. On receipt of new stock, the service shall provide the facility to add units to the inventory, with a default status, using bar code readers without the need for keyboard activity between each unit. The service shall not allow duplication of units in the inventory i.e. it shall not allow units to be accidentally added a second time. The service shall support the use of multi-packs of the same unit. The service shall make it possible to allocate units on the system. The service shall support the facility to specify which unit details are mandatory, for each product type. The service shall provide the facility to store known blood group genotypes of units. The antibody file within the service shall be searched for numbers of antibodies, specificity and reaction strengths for a given time period per patient. The service shall provide the facility to reserve units (e.g. platelets) for patients
Required Response
114.20.5
114.20.6
114.20.7
114.20.8
114.20.9
114.20.10
114.20.11
114.20.12
114.20.13
114.20.14
114.20.15
FINAL 1.0a
Page 226 of 607
ICRS
Requirement during stock entry. 114.20.16 The service shall provide the facility to define which products require cross matching before issue. The service shall provide the facility to antilogous unit allocation to a patient. When a unit is transferred (with a patient) to another hospital it shall be possible to record the destination hospital in the unit details record and print appropriate forms for dispatch with those units. The servi ce shall support the use of batch products with quick receipt/issue procedures. The service shall provide the facility assign multiple user defined statuses to a unit e.g. stock, reserved, crossmatched, issued, issued uncrossmatched, transfused, expired, etc. Alerts for units approaching expiry date shall be available on-screen and/or hardcopy within the service. The service shall not allow expired units to be selected for cross-matching or issuing to a patient. The service shall support unit based searching. The service shall provide the facility where a unit of blood can be read by the bar code reader and the time that a unit is removed from the blood bank recorded. This shall be incorporated as part of the stock control program. The service shall record the time products are returned by the use of a bar code reader. The service shall allow any units that have been issued then returned to be flagged with the period of time that the units were out of refrigerated conditions
Required Response
114.20.17
114.20.18
114.20.19
114.20.20
114.20.21
114.20.22
114.20.23
114.20.24
114.20.25
114.20.26
FINAL 1.0a
Page 227 of 607
ICRS
Requirement displayed. 114.21 General Validation And Safety
Required Response
114.21.1
The service shall provide facilities to prevent the inadvertent allocation of ABO and/or rhesus incompatible blood, to include. warning of minor group incompatibilities; prevention from proceeding with a major group incompatibility; describe the alarms that can be set up e.g. Audio, Visible, Flashing, etc.; and not allowing major ABO mismatched units to be issued to a patient without a positive confirmation from a user with the appropriate level (this is necessary for BMT patients with changed blood groups).
114.21.2
The service shall provide a facility to check a patients current blood group result against previous entries.
114.21.3
The service shall not allow units with recorded blood group genotype to be issued to a patient with a recorded antibody to that genotype. The service shall allow users to specify and configure mismatch tables for red cells, platelets and plasma. When an antibody identity test is resulted, the service shall automatically add this antibody to the patients blood transfusion demographic details. When entering the patients blood group the service shall check against the historical blood group (if available) and warn the user if there is any mismatch. The service shall only allow staff with the appropriate access level to modify patient details that are associated with a blood transfusion request.
114.21.4
114.21.5
114.21.6
114.21.7
FINAL 1.0a
Page 228 of 607
ICRS
Requirement 114.21.8 The service shall provide a user definable facility to enforce validation and confirmation of the entry of blood group, antibody screen and antibody identity. The service shall provide a facility to highlight patient antibody status at the time of: 114.21.10 compatibility testing; requesting; and patient enquiry.
Required Response
114.21.9
The service shall provide a facility to display a summary of patient transfusion history at the time of grouping and cross matching.
114.21.11
The service shall allow for the changing of a patients blood group e.g. after a bone marrow transplant. The above facility shall be secure to prevent inadvertent changes to a patients blood group. Processing Requests Upon requesting a crossmatch, the service shall p rompt for date and time required, the number of units required, requesting Consultant and the reason for transfusion. The service shall provide a facility for entering details of requests for blood grouping, antibody screening, cross matching and requests for blood products including date and time sample taken. The service shall provide an instant patient history to be available from patient screens for user definable tests such as haemoglobin level and platelet count. The service shall allow instant patient transfusion history to be available from patient screens.
114.21.12
114.22 114.22.1
114.22.2
114.22.3
114.22.4
FINAL 1.0a
Page 229 of 607
ICRS
Requirement 114.22.5 The service shall provide patient screens which display pertinent user definable patient details such as blood group, irregular antibodies, special transfusion requirements, free text notes. The service shall provide a functional daysheet facility processing requests. fully for
Required Response
114.22.6
114.22.7
The service shall provide facilities for presenting all outstanding blood transfusion requests in order of date required or specimen number. The service shall provide facilities for recording individual results of serological investigations. The service shall provide facilities for users to define printed worksheets that can be used for entering the results of individual serological investigations.
114.22.8
114.22.9
114,22.10
The service shall print all necessary documentation to support the processing of blood and blood products including: group and cross match forms; compatibility labels; and blood bank register labels. report
114.22.11
The service shall provide a facility to allow the user to issue blood prior to the completion of compatibility tests. The service shall provide a facility to record the issue of, and print special labels for, blood which has been issued as group compatible only i.e. not cross matched. The service shall provide a facility to record the fact that blood that has previously been marked as 'issued as group compatible only' has subsequently been cross matched. The service shall allow further cross matches on a sample before the
114.22.12
114.22.13
114.22.14
FINAL 1.0a
Page 230 of 607
ICRS
Requirement completion of the first. 114.22.15 The service shall include a predetermined order tariff, e.g. three units for a hip replacement, so that if more units are requested the operator is alerted and can take appropriate action. Processing Blood The service shall support the recording of receipt and issue of all blood and blood products (both single and batch). The service shall support the recording of the movement of all blood and blood product (both single and batch) related data including receipt, issue, processing and the final fate of the unit. The service shall support the use of user definable tags for units of blood e.g. Kell Neg, R1R1, CMV Neg. The service shall support the production of user definable on-line stock summaries, output to screen or printer, selected by group, product type or special flag e.g. CMV Negative, as required, grouped by product or blood group, and in expiry date and donor/batch number order. The service shall provide stock enquiry functions to differentiate between reserved and non-reserved blood.
Required Response
114.23 114.23.1
114.23.2
114.23.3
114.23.4
114.23.5
114.23.6
The service shall have the ability to be used to perform the so called computer crossmatch and therefore shall be able to interrogate the computer used by the NBTS (when the service is introduced and available). The service shall have the facility to record screening tests performed outside the laboratory for blood and stem cell donations. The service shall record autologous blood and stem cell donations as
114.23.7
114.23.8
FINAL 1.0a
Page 231 of 607
ICRS
Requirement separate products. 114.23.9 The service shall support the entry of the same donor unit and product type for different recipients e.g. use of multiple (quad, six, etc.) packs. If a unit has previously been found to be incompatible for a patient then the service shall not allow that unit to be reselected for cross-matching for that same patient at a later time. The service shall provide the facility to add further unit orders to a request. The service shall warn the user when accessing a sample for grouping/screening/cross-matching if that sample is older than a user-defined time period (normally three days). The service shall be able to generate and print user-defined worksheets for a batch of cross-matches. The worksheet shall automatically accommodate rack position, auto-controls and positive/negative controls. For products that normally require cross matching, the service shall ensure that in an emergency situation, this event is by-passed and uncross-matched units can be issued. The service shall support electronic issue for uncross-matched blood, based on historical blood group/tile group and blood group/antibody screen. The service shall alert users of outstanding units with a status of issued uncross-matched. The service shall provide the facility to print a theatre list i.e. a list of patients with associated number of units crossmatched who are due for theatre on a user specified date. The service shall automatically print user defined compatibility/issue slips and unit labels at the cross-match or
Required Response
114.23.10
114.23.11
114.23.12
114.23.13
114.23.14
114.23.15
114.23.16
114.23.17
114.23.18
FINAL 1.0a
Page 232 of 607
ICRS
Requirement issue stage on user defined stationery. 114.23.19 The service shall provide on-screen and/or hardcopy list of units due/overdue to be returned to stock after being reserved for a user definable period. The service shall have the ability to log and recall the issue of units of blood, which do not have an exact match with the recipient. There shall be provision in the service for results to be stored as reactions as well as interpretations. Audit Trails The service shall support the production of reports on the receipt, processing, usage, disposal and stock movement of all blood and blood products (both individual and batch). The service shall support on-line searches of transfusion histories, including: listing all blood and blood products (both individual and batch) an individual patient has received; and listing the movements of an individual unit of blood or blood product (both individual and batch) from receipt to final fate of product.
Required Response
114.23.20
114.23.21
114.24 114.24.1
114.24.2
114.25 114.25.1
Antenatal Testing The service shall generate blood group cards for all antenatal patients. The service shall provide facilities to support antenatal serology. The service shall support the recording of the receipt and issue of prophylactic anti-D immunoglobulin. The service shall support all necessary testing concerning anti-D prophylaxis, including:
114.25.2
114.25.3
114.25.4
FINAL 1.0a
Page 233 of 607
ICRS
Requirement testing and reporting of mother and baby samples (blood group, antibody screen and direct antiglobulin test); initial Kleihauer testing in mother's blood; issue of anti-D immunoglobulin; and any subsequent repeat Kleihauer testing and issue of anti-D immunoglobulin.
Required Response
114.25.5
The rules base provided by the service shall support the automatic interpretation of mother and baby blood groups to: determine appropriate comment or generate e.g. 'Kleihauer not indicated'. generate requests for Kleihauer testing if indicated.
114.25.6
The rules base shall provide the facility to automatically calculate anti-D immunoglobulin dosage from the Kleihauer result. Statistical Reports The service shall allow the production of reports showing all requests (group and save, crossmatch, etc.) and blood and blood product utilisation for Consultant or speciality for procedure/clinical condition. All National Blood Transfusion Service statistics and user definable management reports shall be supported. The service shall produce a log of all products issued with special requirements e.g. CMV screened, irradiated blood. The service shall provide the management information detailed in BCSH Guidelines for Documentation and Procedures 1990 and BCSH Guidelines for Hospital Blood Banking Computing 2000.
114.26 114.26.1
114.26.2
114.26.3
114.26.4
FINAL 1.0a
Page 234 of 607
ICRS
Requirement 114.26.5 The service shall provide a link to the National Blood Tr ansfusion Centre for electronic transfer of stock data. The service shall produce detailed management and financial reports on the usage and cost of all generic blood and blood product types by requester, speciality and/or practice location. The service shall accept different costs for the same batch/lot numbers during the financial year for each blood/blood product. Product Administration The solution shall comply with guidelines for electronic issue (computer cross-matching). The service shall be flexible such that it will permit modification of procedures to meet clinical governance targets. It shall be possible to assign conditions to patients that result in warnings to operator. These warnings to be logged if not met e.g. allocating group O to a group A patient. The service shall assign conditions to grouping, crossmatching and antibody detection. The service shall allow rules based analysis to control the issue of blood products (e.g. blood group, sub group, blood product). The service shall have the facility to manage blood products which have their compatibility testing performed elsewhere e.g. NBA, patients transfused with blood cross-matched at another hospital. Other Requirements The service shall not: require bar code start and stop codes to be entered during
Required Response
114.26.6
114.26.7
114.27 114.27.1
114.27.2
114.27.3
114.27.4
114.27.5
114.27.6
114.28 114.28.1
FINAL 1.0a
Page 235 of 607
ICRS
Requirement keyboard entry of bar codes. display bar code start and stop codes on screen or in print at any time.
Required Response
114.28.2
The service shall be capable of being interfaced to the blood grouping/antibody screening machines. The uploading of all patients blood group, antibody data, special requirements, and all blood product data on the current system into the new system is required by some sites. The service shall retain patient/blood product on-line for a user-definable period. The service shall be able to send/receive stock orders electronically when the local Blood Transfusion Service is able to offer this facility, or the use of disk/CD ROM as appropriate. The service shall allow electronic ordering at ward level ordering of further units of blood for transfusion. Strict user-definable rules based criteria shall be in place for this process. The service shall alert the laboratory to these further requests and a positive intervention to acknowledge receipt of requests shall be in place. The service shall allow for real time electronic tracking of blood units. The introduction at ward level shall allow for positive ID technology to control the checking process of units of blood for transfusion. The service shall be able to store blood unit specific data such as CMV Negative, irradiated, washed RBCs etc. The service shall allow user defined additional criteria to be added/amended as necessary. The service shall provide the facility to reprint compatibility labels/reports called by specimen/Laboratory number as well as other user definable criteria such as Each bidder shall indicate how this will be supported. Each bidder shall indicate how this will be achieved.
114.28.3
114.28.4
114.28.5
114.28.6
114.28.7
114.28.8
114.28.9
FINAL 1.0a
Page 236 of 607
ICRS
Requirement location, runnumber, consultant etc. 114.28.10 The service shall not allow the issuing of incorrect units for patients with specific requirements e.g. CMV Negative, washed irradiated RBCs, etc. These patient specific requirements may change and any additions/deletions made shall be controlled by password privilege levels. These changes shall be logged and alerted to any user upon further patient related product request for a user defined time period. Details of issue of anti D including dates, dosages and lot numbers shall be stored against a Patient Record. The service shall indicate on reports, if appropriate, the date repeat samples are required. The service shall list dates of when repeat antibody investigations are required for patients with positive antibody identifications. Anti-Coagulation Subject to access restrictions controlled by the laboratory, the service shall allow remote users to view and change both dosage and treatment information. Outlying results shall be alerted to clinical laboratory staff for intervention. The service shall allow printing of dosage cards (card printer). The service shall provide alternative methods of dose/date printing, such as label printing with user defined label types and formats available. The service shall allow automatic derivation of dosage and appointment time/dates using a recognised algorithm e.g. 'Charles' algorithm: BMJ 1984,289,422-424. The service shall have a user definable clinical intervention screen for
Required Response
114.28.11
114.28.12
114.28.13
114.29 114.29.1
114.29.2
114.29.3
114.29.4
114.29.5
FINAL 1.0a
Page 237 of 607
ICRS
Requirement confirmation/alteration of dose/appointments as defined by rule based criteria for any abnormal/referral results. 114.29.6 The service shall allow full user defined tablet/dose criteria. The service shall have a full recall package in place with a series of user defined recall letter options available. The service shall have the ability to receive patient referrals by e-mail. Radiology Requirements The service shall provide tables in the product. central
Required Response
114.29.7
114.29.8
114.30 114.30.1
Each bidder shall describe what these contain and how they are maintained. Each bidder shall describe what these contain and how they are maintained.
114.30.2
The service shall include facilities for local site customisation (e.g. sites/clinics/Primary Care practitioners/clinical staff). The service shall be flexible and capable of development in response to local or national requirements. The service shall be capable of using bar coding equipment.
114.30.3
114.30.4
Each bidder shall describe what facilities are available and what equipment would be needed to use the facilities.
114.30.5
The service shall be capable of supporting DICOM 3 plus extensions, digital imaging management and shall be compatible with ACR-NEMA. Each bidder shall describe any voice recognition system available or under development to work with their product. Patient Personal And Demographic Details Each bidder shall use the PDS for Personal and demographic details of the patient. Each bidder shall describe the patient search facilities available. Minimum requirements are:
114.30.6
114.31
114.31.1
114.31.2
FINAL 1.0a
Page 238 of 607
ICRS
Requirement 114.31.3 by hospital number; by NHS Number; by radiology number; by surname and forename; and by date of birth.
Required Response
Each bidder shall describe what information will be shown as a result of a patient search in the event of no, one or several matches on the search criteria. Each bidder shall describe how duplicate registrations of the same person can be corrected and whether such corrections can be undone if a mistake is made. The service shall display the current film location and date that the packet was sent. Each bidder are invited to describe any fast track facilities for recording limited amounts of data for new registrations. Appointment Scheduling This section describes the facilities needed to assist in the efficient use of examination rooms and other imaging resources and the service shall include as a minimum: unique identifier for the resource; separate time zone for each resource; the sessions the resource is available; the number of days in advance that the resource may be booked; the examinations which can be booked into the resource; the timing and sessions available for these examinations; scheduling rules and number of examinations permitted; and periods during which the resource is unavailable and the reason.
114.31.4
114.31.5
114.31.6
114.32 114.32.1
114.32.2
The service shall support the automatic generation of diary pages for each resource using a template.
FINAL 1.0a
Page 239 of 607
ICRS
Requirement 114.32.3 The service shall provide the ability to easily alter the defaults within the template at the time of booking an examination. This facility shall apply to that examination only. The local system administrator shall be able to indicate resource unavailability for: 114.32.5 periods within a session; single sessions; a number of sessions; an extended period of time; and and the reason for this unavailability.
Required Response
114.32.4
The service shall ensure that the local trust system administrator is able to alter template(s) including: resource unavailability for one resource, for selected resources, or for all resources; subsequently changing the period, or availability of the room; and allowing for overbooking of time slots.
114.32.6
Each attendance may involve more than one examination (e.g. head, shoulder, leg). It shall be possible to record the following information against each attendance: radiographer(s): usually one; other radiography staff; time radiographer collects patient; time radiographer completes examinations; comment field for radiographer; the fluoroscopy screening times; record of non-film Consumables; room(s) used for examinations; contrast medium, type and amount; name and amount of any other medication required; examinations requested; examinations performed; radiologist involved in the examination; summary of the numbers and types of films used; and
FINAL 1.0a
Page 240 of 607
ICRS
Requirement 114.32.7 patient time in the department and time that the patient left. The service shall display the booking of any resource in a diary format. The service shall have the ability to review the status of bookings for an individual patient. The service shall allow for the booking of multiple examinations for one patient. Some of these examinations may be in different areas of the department e.g. ultrasound, mammogram; the service shall search for the appropriate slots. The service shall automatically detect and warn against booking or scheduling conflicts, so that patients are not scheduled for simultaneous procedures. The serve shall include the facility to alter to the default examination time when booking an appointment. The service shall interface with eBooking in order to provide the following facilities: cancellation of appointments or the appointment date and time, the cancelled slot then being freed for other patients. recording the user, the date and the reason for the cancellation/rebooking. recording whether the hospital or the patient cancelled the appointment and how many times the appointment has been cancelled/rebooked.
Required Response
114.32.8
114.32.9
114.32.10
114.32.11
114.32.12
The local trust system administrator shall be able to define conflicting procedures that are too close together or clinically dangerous in combination. The rules for such special booking arrangements for individual examinations shall be System Manager definable. The facility to issue appointments for injections for nuclear medicine procedures prior to scan appointments is required.
FINAL 1.0a
Page 241 of 607
ICRS
Requirement 114.32.13 As a minimum the information required to make an appointment shall be and the service shall provide: 114.32.14 the patients surname and first forename, or equivalent substitute if patient identity is unknown; the date and time the booking was made; the clinician requesting the examination; the person booking the examination. the examination(s); clinical or other notes in free text; the status of the patient (i.e. inpatient, outpatient, GP patient etc.); the location of the patient; and transport or collection requirements.
Required Response
The service shall display a list of previous examinations for the patient at the time the booking is made. The service shall also have the ability to view the patients hospital(s) attendance record, including upcoming appointments. Customised appointment letters/preparation forms linked to the examination(s) which have been booked are required. The ability to link customised preparation/instruction forms to each booked examination shall be available within the service. The service shall provide a search facility to identify preparation forms, which are not the default forms, is required e.g. different preparation form for barium enema for IP, OP, and diabetic patient. The service shall provide a facility to edit preparation forms at the time of booking and before printing. The service shall ensure the facility to reprint all documentation linked to a booking at the request of the user can Each bidder shall describe the flexibility of the solution to cater for single and multiple appointments.
114.32.15
114.32.16
114.32.17
114.32.18
114.32.19
FINAL 1.0a
Page 242 of 607
ICRS
Requirement be carried out at any time. 114.32.20 The service shall provide customised appointment lists to assist clerical staff preparing documentation for patients with appointments shall be able to be produced at the request of a user. Patients not attending appointments shall be easily identified and displayed. The service shall provide facilities for each radiology site to set up and maintain their own set of time zone definitions, e.g. standard, site 1: 9am 5pm Monday to Friday, standard, site 2: 8.45am - 4.45pm Monday to Friday urgent, site 1: 5pm - 12pm Monday to Friday, all day Saturday, all day Sunday etc. Examination section 3.24) Requests (See also
Required Response
114.32.21
114.32.22
114.33
114.33.1
This section deals with the entry of data on the solution for individual examinations. This is the most frequently used facility and accurate entry is vital for workload and management statistics. Many examinations are not pre-booked and rapid entry of data onto the system is required. Details of all examination requests received by the department shall be stored and not overwritten by subsequent requests. Where appropriate the service shall request that the user identifies the side to be examined. When a request is entered the service shall, on request, display a list of previous imaging examinations for that patient in reverse date order i.e. most recent examination first. When a request is entered the service shall guide the user through the entry process efficiently to ensure that all the appropriate record keeping and data
114.33.2
114.33.3
114.33.4
114.33.5
FINAL 1.0a
Page 243 of 607
ICRS
Requirement capture tasks are carried out. 114.33.6 A fast track facility shall be available to enter a request using minimum patient and examination data. It shall be possible to proceed to the examination reporting stage on this minimum dataset and to add data about the examination either before or after reporting. A facility to view previous examination reports at the time the request is entered onto the service shall be available. A facility to enter the patient onto the service prior to the date and time of his arrival in the Radiology department shall be available. The ability to cancel a patients examination entry and to keep as a minimum a record of: the date of cancellation; the reason for cancellation; the user who was responsible for the cancellation; and when an examination entry is cancelled the data shall be displayed but flagged as cancelled with a reason.
Required Response
114.33.7
114.33.8
114.33.9
114.33.10
114.33.11
The service shall have facilities to amend examination details including the referring doctor and source; if this is carried out after the approval of the examination report this shall be security controlled. The service shall provide the ability to change the date of an examination prior to its scheduled date. The service shall automatically generate a film pull list if films are not available or required immediately and print, on request, to a user-defined printer. The service shall have the facility to print a notification list for inpatient
114.33.12
114.33.13
114.33.14
FINAL 1.0a
Page 244 of 607
ICRS
Requirement examinations, which shall contain any necessary dietary or medication notes associated with the booked procedure. 114.34 114.34.1 Management Of Patient Throughput In addition to the resource booking facilities it shall be possible to use the scheduling and examination requesting information to assist with the management of the flow of patients through the radiology department. Each attendance may involve more than one examination or more than one visit to the examination room. Each bidder shall describe the methods by which the solution assists with the control and recording of activi ty within the department. The service shall have the facility to view on screen or print in user defined order, lists of incomplete examination records for subsequent follow up and completion. The service shall have the ability to print a variable number of copies in a user defined order, a list of activity which has taken place in the department. The service shall support the need to produce a daily list of entered activity for each resource/group of resources in a user-defined order. Each bidder shall describe how the service will record details of the key items of examinations performed, the staff involved, including anaesthetists and nurses when present, materials used (both type and amount) and the outcome. Reporting Examinations Of Radiology
Required Response
114.34.2
114.34.3
114.34.4
114.34.5
114.34.6
114.34.7
114.35
114.35.1
The reporting process is complex, and the service shall provide help and guidelines for the person generating the report and for the person inputting the
FINAL 1.0a
Page 245 of 607
ICRS
Requirement information. 114.35.2 The reporting process has two stages, reporting and approving the report. These stages may be concurrent or may be separated by time. Each bidder shall describe the reporting facilities available to the user. The service shall be capable of running a hot reporting service. The facility to define standard report formats and to automatically process classification and report text to produce formatted output is required. The service shall have the facility to define a number of standard reports/phrases and edit and extend this dictionary. The ability to record some standard reports in the format of a tick sheet or yes/no boxes e.g. whether ultrasound is required. The service shall have the facility for direct entry of free text data by a user such as a medical secretary or radiologist/radiographer. The service shall support the need to record examination details before the text of the report. The service shall have the ability to report multiple examination requests for the same patient with the same report text appearing against each request and one report being printed e.g. a series of examination requests on the same patient. It shall also be possible to block report patients with the same report. The service shall have a spell check facility using a medical dictionary with facilities for a user-generated supplement.
Required Response
114.35.3
114.35.4
114.35.5
114.35.6
114.35.7
114.35.8
114.35.9
114.35.10
114.35.11
FINAL 1.0a
Page 246 of 607
ICRS
Requirement 114.35.12 A facility to enter two reporting clinicians into the reporting module and for their names and designations to be printed as part of the report header is required. Each bidder shall describe how the solution manages: 114.35.14 incomplete exams; unapproved examinations by radiologist/ clinician; approval process for examinations by radiologist/clinician; and access to previous reports.
Required Response
114.35.13
The service shall support the production of DICOM structured reports. The service shall include a facility to move directly from insertion of examination details, e.g. radiology number, to the report of the same examination. Ultrasound The service shall have the ability to receive and present graphical and numerical data related to imaging procedures as appropriate, for example obstetric ultrasound. The service shall provide the same functionality for all modalities which require graphical presentation/interpretation of data output, for example: bone densitometry scanning. isotope renography. MRI spectroscopy.
114.35.15
114.36 114.36.1
114.36.2
114.36.3
The ability to convert obstetric measurement data, (biparietal diameter, head circumference, abdominal circumference and femur length) into gestational age is required. The ability of the user to enter the reference charts for this is preferred, but the availability of pre programmed standard charts would be advantageous. The service shall have the facility to convert biparietal diameter to arrive at a
114.36.4
FINAL 1.0a
Page 247 of 607
ICRS
Requirement gestational age into estimated date of delivery. 114.37 114.37.1 Classification Of Examinations The classification process shall allow for the input of either the complete classification code, or parts of the code, with interactive assistance to complete the coding. The code shall include the following: 114.37.2 organ examined; whether the results of the examination were abnormal or normal; the anatomical site; and the pathology observed.
Required Response
The service shall provide the facility for suitably authorised users to amend classification codes for examinations and an Audit Trail maintained of this activity. The service shall provide a medical dictionary which supports a search facility for medical terms e.g. to identify pathology. The service shall provide the functionality for the reporting clinician to select user specified codes and have these automatically downloaded to a file to assist in the setting up of a teaching file or for examples of pathology. The service shall provide the facility to enter automatic or semi-automatic text to code generation facilities or a coding assistance. Storage, Dispatch And Retrieval Of Examination Reports Where an approved report has been amended the service shall provide a facility to print the text of the report. The service shall support the sorting of approved examination reports into Trust defined electronic mailboxes (or similar) for onward transfer to previously defined destinations. This could be via
114.37.3
114.37.4
114.37.5
114.38
114.38.1
114.38.2
FINAL 1.0a
Page 248 of 607
ICRS
Requirement EDIFACT messaging for direct transfer of reports to Primary Care practitioners via ICRS. This process shall be expandable and system manager definable. 114.38.2 The header of the report shall include: 114.38.3 full patient name and title; NHS Number; radiology unique patient identifier; examination unique identifier; names and designations of up to two reporting clinicians; date of examination; the date the examination was reported by the radiologist; the name of the ordering clinician; the address of the GP practice (if direct referral) or by GP practice code; and the typists initials.
Required Response
The content and format of the report shall be user definable and shall include the examination requested and side (if appropriate). There shall be a clear distinction between unapproved, approved and amended reports. The service shall provide facilities for clinical audit based on radiological reports, based on coded fields and also an audit of report free text. X-Ray Film Library Management X-ray films are stored for a considerable time, and the work involved with the management of the film library and the location and retrieval of film envelopes can constitute a major task. Suppliers are asked to describe how their solution would provide facilities to assist with this. The service shall capable of supporting a digital archiving library as well as a hard copy film library.
114.38.4
114.38.5
114.39 114.39.1
114.39.2
FINAL 1.0a
Page 249 of 607
ICRS
Requirement 114.39.3 The service shall have a facility to define the permanent film library to which the film envelope is assigned. The service shall provide a facility to record the current location of a film envelope and the date booked out to that location. The service shall provide a facility to view on the screen previous destinations of the film envelope together with the dates booked to that location and who they have been booked out to. Logging films in and out shall be both accurate and easy to use. The service shall provide a facility to record the movement of individual film examinations as well as the film envelope. There shall be a simple merge facility when these individual examinations are returned to the film envelope. The service shall provide a free text facility of minimum 150 characters for use when a film envelope is sent outside the hospital. The service shall provide a facility to mark the patients date of death where applicable. The service shall provide a facility to generate a user definable list of film envelopes required for booked examinations and print to a user definable printer. The service shall provide a facility to generate a list of film envelopes which are due for removal to secondary storage. The criteria for moving film envelopes will vary. The service shall provide a facility to cull the library for films that can be removed for reprocessing and silver reclamation. Users shall be able to specify the period that a film is retained
Required Response
114.39.4
114.39.5
114.39.6
Each bidder shall state their suggested mechanism for this.
114.39.7
114.39.8
114.39.9
114.39.40
114.39.41
114.39.42
FINAL 1.0a
Page 250 of 607
ICRS
Requirement before this occurs, and to mark films for permanent retention. 114.39.43 The service shall provide a facility to generate a user defined list, set out in terminal digit order or by date of birth, and by examination year of film envelopes due for culling. The service shall support bar-coded identification of film envelopes. The bar code equipment shall be compatible with the terminals proposed. It shall be possible to mark film envelopes with a minimum date of retention. The service shall provide a facility to notify overdue loans. Training Each bidder shall list type of training provided and estimated duration in minutes and/or hours for the following staff groups: 114.40.2 users; receptionists; secretaries; radiologists; local trust system administrator; system support staff; radiographers; nurses; radiographic assistants; health care scientists; AHP; students and other trainees.
Required Response
114.39.44
114.39.45
114.39.46
114.40 114.40.1
The service shall support the Integrated Health Environment (IHE) standards being set at international, continental and national levels. Prescriptions Pricing Agency (PPA)
114.40.3
The service shall link with the PPA to ensure that prescriptions generated by GPs and other community staff are copied to the PPA as an audit
FINAL 1.0a
Page 251 of 607
ICRS
Requirement backcheck against fraud Audit 114.40.4 The service shall support audit of individual precribing practices. It shall automatically generate reports and returns against locally generated criteria and support ad hoc reporting as required by authorised individuals. Within the service, key costing information shall be linked to the prescription to enable costed treatment to assessed.
Required Response
114.40.5
FINAL 1.0a
Page 252 of 607
ICRS
115 - DIGITAL IMAGING INCLUDING SPECIFICATION FOR A PICTURE ARCHIVING AND COMMUNICATIONS SYSTEM (PACS) SOLUTION Overview This module specifies the requirements for the service provider to enable management and distribution of digital images used for clinical purposes. An integrated care record shall include a wide range of non-textual information; e.g., graphs, scans, etc. An important element within the record shall be digital images. This section describes the requirements for collection, management and presentation of digital images, functionality commonly referred to as a Picture Archiving and Communications System (PACS). Scope Components Initially restricted to static radiological images and associated reports, but rapidly expanding to cover other disciplines, including dermatology, orthopaedic surgery, endoscopy and cardiology. Needs to link to existing (or replacement) radiology management systems demographic and administrative/scheduling functions (e.g. Patient Administration Systems/functions) to allow for pre-fetching and auto-routing. Supports transfer of individual images/reports (or the images/reports for an individual) between health communities generally through a remote viewing process, rather than actual transfer.
Dependencies There are already standards for PACS (DICOM and HL7v2), however interoperability between systems is not guaranteed by the use of the international versions of these standards. These are being profiled for UK through HL7-UK and the parties involved in the Integrating the Healthcare Enterprise (IHE) UK activity. Early installations would require the transition from the current use of HL7 v2.x in IHE-UK specificities documentation to HL7 v3 analogues which provides equivalent or superior functionality. Although IHE is not a standard but a method of specifying and then demonstrating the interaction of the standards it currently provides a basis for both conformity and interoperability tests beyond the conformance tests contained in DICOM, which do not themselves guarantee interoperability. Diagnostic message standards work, see: Modules 770 and 790.
Benefits and Outcomes Scenarios (a) Managing Joans Chronic Illness and Leg Ulcers. The GP and specialist nurse can monitor the leg ulcer care and Joan's retinal scans through the digital imaging system.
FINAL 1.0a
Page 253 of 607
ICRS
(b) James Heart Attack James is reviewed and referred for a coronary heart bypass graft assessment. The heart surgeon is able to review all of the images (echocardiogram, chest X -ray, and ECG tracing) from the general hospital and compare them with more recent tests arranged at the specialist hospital.
(c) Mohamed Breaks His Leg An x-ray taken for Mohamed as a child shows an abnormality. If his previous films had not been available (because they were taken before PACS and in a different part of the country), then an apparent abnormality which is in fact a past Episode might have been misinterpreted as a new condition resulting in unnecessary intervention.
(d) Infant Penny has a rare life threatening genetic disorder Six year old Penny has MPS (Mucopolysacrodosis), a rare aggressive and degenerative genetic disorder. This is first diagnosed at Hospital (A) from the ophthalmic reports at the Eye Hospital (B). As a consequence she is admitted to Childrens Hospital (C) to be operated for a VP shunt to equalise her CSF pressure (due to communicating hydrocephalus). As a consequence of the initial diagnosis and in order to plan treatment, she has to have a lumbar spine MRI scan at Hospital (D) and an echocardiographic scan at the Heart Hospital (E). Through the use of the multi-site digital imaging system integrated with the single patient care record, her retinal images; her skull x-ray and CT images; her lumbar spine MR images, her cardiac scans and her complete care records can all be seen together at Hospital (A), thus empowering her primary paediatric clinician to give her a planned path to timely and lifesaving, care and treatment.
Desired Benefits and Outcomes To: Patient Reduction in repeat investigations and in the case of radiology, exposure to radiation. Clinician Initial roll-out for key areas (e.g. radiology department, A&E etc.), and to support emerging care settings. More information available to inform patient care. One image available in many places at same time. No lost films. Faster reporting (no need for physical collection/amalgamation of films). Manager
Supports redesign of imaging referrals and services (e.g. use of DTCs, remote diagnostics, etc.). Reduced requirement for film storage. No (or a much reduced) requirement for manual film distribution/library. In time, it shall be necessary to support the capture and presentation of all images in the following contexts: Specialty Digital Image Requirement
FINAL 1.0a
Page 254 of 607
ICRS
Specialty A&E
Digital Image Requirement Photographs of wounds of open fractures and hand injuries. Live transmission of pictures from theatres. Intra-operative imaging and pre/per-operative viewing. Transoesophageal Transthoracic echocardiography (ultrasound images); Angiography (typically on CD currently); Magnetic Resonance Imaging (MRI), including moving MRIs.
Theatres/Critical Care Cardiology
Chiropody
Digital cameras for recording images. A gait lab for analysing patient gait and pressure distribution.
Dermatology Imaging Liver
Sequential or single digital images of skin rashes, lesions and tumours etc. General storage of video clips. Endoscopic ultrasound. These images are real-time ultrasound images and a digital video recording is required. An ability to store endoscopy images, endoscopy video and ERCP film images shall also be useful. Overnight video recordings, Computerised Tomography (CT), MRI and still photography Replacement of some clinical images with short video clips. There is current widespread use of digital cameras and an image archiving system. Need links to other images available for patients, including but not limited to neuroimaging, clinical photography, visual fields, biometry including ultrasound, orthoptic investigations, videos of eye movements to detect abnormalities etc. Fluorescein angiograms. Clinical photographs. Anterior and posterior segment of the eye. Videos of operations.
Neurology/Sleep labs
ENT/Maxillo-facial Ophthalmology
Pathology
Histopathology: heavy use of digital cameras to record specimens. Libraries of digital images of gross and histology specimens e.g. networked colorectal database. Digital image capture and storage facility for e.g. electron microscopy.
FINAL 1.0a
Page 255 of 607
ICRS
Specialty Radiology
Digital Image Requirement X-ray radiography e.g. angiography, chest, dental, mammography. MRI. CT. Ultrasound (US). Nuclear Medicine. Fluoroscopy /Lithotripsy.
Radiotherapy
Portal imaging, treatment plans, patient outlines (osiris), shielding block diagrams, MLC positions, simulator digital therapy images (digital radiographs), digital camera images of radiotherapy treatment set-ups. Video or static pictures from operations in theatre. Photographs of skin changes, deformity, ulcers etc. VHS videos of nasendoscopies, as well as still pictures and videos of the whole patient. Snap-shots and video, including good voice quality to understand and assess specific communication swallowing difficulties. (Currently make videos of x-ray swallows (videofluoroscopy), nasendoscopies, patients communicating, eating and drinking, audio tape recordings of patients, still photos of nasendoscopies).
Renal Surgery Rheumatology Speech and Language Therapy
Dental Surgery
High definition films of the oral and buccal cavity. Digital cameras/video to record patient stoma siting. Video of operative procedures.
Vascular surgery
Angiographic imaging extensively as well as lots of CT and US, plus a small amount of MRA. Duplex vascular US findings as an anatomical diagram of the human arterial tree, with stenoses and occlusions blacked in and numerical data such as sphygmo cuff pressures, flow velocities and estimates of % stenoses appended. Machine for recording calf muscle contractility in oscilloscope form. Digital camera images for monitoring leg ulcers. Development of a digitised standard scoring system would be a major advance to record varicose veins photographically.
Signal data (such as 24h ECG, pressure monitoring, plethysmography records, pressure/volume records from bladder studies/urodynamics, respiratory flow-volume loops, EEG, etc.) are not images but are amenable to archiving and retrieval in a manner analogous to PACS and it is likely that in the future a service shall be developed to manage these.
FINAL 1.0a
Page 256 of 607
ICRS
Previous Experience/Lessons Learned The advent of digital modalities such as CT and MRI, particularly in light of the recent New Opportunities Fund (NOF) and Capital Investment Programme (CIP) central initiatives, has seen a need to manage and store the clinical images obtained with the associated patient demographics through PACS. Consequently, the drive towards PACS is inexorable and, if left to individual sites, may result in dozens of disparate systems with the associated interoperability problems as seen with Radiology Information Systems (RIS). This scenario would limit the ability to achieve ICRS. Additionally, the purchase of PACS by individual Authorities shall mean the NHS shall incur the procurement costs hundreds of times and not be able to access bulk purchase benefits that a national initiative would provide. Desirable Service Characteristics Integration of PACS/specialty information solution (e.g. RIS) functions for each community using a single PDS and providing full desktop integration. Such criteria shall always be output-basedtherefore where LSPs do not offer both PACS and RIS, they may (for radiology) offer integrated products, including those of another contractor. However, the LSP shall take responsibility for the performance of the integrated solution. A desirable scenario would be for an integrated solution using web technology on industrystandard hardware. Other criteria would be the need for all images to be stored in a DICOM format (including web solutions), particularly on removable media. Other key areas for consideration are security issues and archiving. A solution would lend itself to storage area network (SAN) solutions. Such solutions could also cater for other storage needs, thus providing cost effectiveness. Experience from current PACS sites suggests that most recalled images are less than a year old and as such, back-up archives at SHA level could be held at virtual Cluster data warehouses.
FINAL 1.0a
Page 257 of 607
ICRS
Imaging specific terminology and standards A modality can be any (but not limited to) of the following: MRI, CT, NM, US, CR and DR equipment. Images from the modality shall be required to be sent into an open network environment, initially a PACS. This communication shall adhere to DICOM the industry standard. DICOM defines Service Classes (Store, Print etc.) and object classes (modality images, worklists etc.) which are combined in Service Object Pairs (SOPs), for which each device may be one or both of Service Class User (SCU) and Service Class Provider (SCP). For further detailed definitions of image related standards and terms that may appear in this section readers are referred to the following websites: DICOM:..................................................................................................... http://medical.nema.org/ HL7 UK with links to US site: ....................................................................... http://www.hl7.org.uk/ DoH MHRA PACSnet with link to glossary:............................................... http://www.pacsnet.org.uk Integrating the Healthcare Enterprise (IHE) UK with links to European and US sites:. http://www.iheuk.org/
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) It is expected of service providers that as a minimum there will be rollout of enterprise-wide PACS st across one third of all Acute Trusts by 31 December 2004.
Minimum Level to Be Achieved by December 2006 (Phase 2) It is expected of service providers that as a minimum there will be rollout of enterprise-wide PACS st across one third of all Acute Trusts and Primary Care Trusts Minor Injury Unit by 31 December 2006.
Target for 2010 It is expected of service providers that there will be full Community-wide deployment of enterprisest wide PACS, where network access allows, by 31 December 2010.
Overview Requirements Requirement 115.1 Overview Required Response Each bidder shall describe its approach to integrating digital imaging within the ICRS. Identify any requirements or limitations that might apply to integrating digital imaging solutions with other components of the ICRS.
FINAL 1.0a
Page 258 of 607
ICRS
Requirement General Imaging and Standards Requirements (in addition to those specified in 790) 115.1.1 The Authority requires a range of PACS products from different suppliers to be available to each LSP bidder including suppliers products that are currently commonly used across England. Offers of single source supply of PACS suppliers shall not be considered. The service shall adhere to DICOM 3.0 and its successors, to enable interoperability of multiple vendors equipment in a network environment. DICOM Service Classes for PACS & Modality interoperability A modality can be any (but not limited to) of the following: MRI, CT, NM, US, CR and DR equipment. Images from the modality will be required to be sent into an open network environment initially a Picture Archiving & Communications System (PACS). This communication must adhere to DICOM the industry standard. DICOM defines Service Classes (Store, Print etc) and object classes (modality images, worklists etc) which are combined in Service Object Pairs (SOPs) for which each device may be one or both of Service Class User (SCU) and Service Class Provider (SCP). The service provision shall ensure that the modality and the PACS solution have the following mandatory DICOM capabilities: Modality Push (DICOM C_Store): The requirement is that the modality shall send images to the PACS. Therefore, the modality shall be a SCU of the C_Store service for all applicable SOPs. Modality Worklist: The requirement is that the modality shall implement the DICOM Modality Worklist service to retrieve schedule information and patient demographics at the modality console from the PACS to avoid reentering information. Therefore, the modality shall be a SCU of the Modality Worklist service.
Required Response
Each bidder shall describe how they fulfil this requirement.
115.1.2
Each bidder shall describe how they fulfil this requirement. The bidder shall confirm ability to to deliver each of these DICOM functionalities with respect to their proposed solution (including reference to actual implementations).
115.1.3
FINAL 1.0a
Page 259 of 607
ICRS
Requirement Print Service: The requirement is that the modality shall use the DICOM print service to enable the use any DICOM compatible networked printer. Therefore, the modality shall be a SCU of the DICOM print service. PACS Push (DICOM C_Store): The requirement is that old images shall be made available at the modality console from the PACS, i.e. for comparative studies. Therefore, the PACS shall be a SCP of the C_Store service for all applicable SOPs. Modality Performed Procedure Step (DICOM N_Create and N_Set): The requirement is that the modality shall use the DICOM Modality Performed Procedure Step service to inform the PACS that an examination is in progress or has been completed. Therefore, the modality shall be a SCU of the Modality Performed Procedure Step service. DICOM Storage Commitment: The requirement is that the PACS takes responsibility for the images that are sent from the modality to the PACS and that once the PACS notifies that the images are committed to be stored, the modality can delete them from its temporary storage. Therefore, the PACS shall provide the DICOM Storage Commitment Service as an SCU to request the guarantee that the images are stored within the PACS. DICOM Query/Retrieve (DICOM C_Find and C_Move): The requirement is that using the DICOM Query/Retrieve Service, the modality shall query the PACS regarding previous studies that were performed on a patient and should be able to retrieve the study. Therefore, the modality shall be a SCU of the C_Find and C_Move services for all applicable SOPs. PACS Pull (DICOM C_Find and C_Move): The requirement is that using the DICOM Query/Retrieve Service, the modality should allow the PACS to
Required Response
FINAL 1.0a
Page 260 of 607
ICRS
Requirement query the modality regarding any images or studies that were performed on a patient and have not yet been sent to the PACS. Therefore, the modality shall be a SCP of the C_Find service and a SCU of the C_Move service for all applicable SOPs. Modality Verification (C_Echo): The requirement is that using the DICOM Verification service the modality shall be able to verify the existence and state of its configured destinations. Therefore, both the modality and the PACS shall be both a SCU and a SCP of the DICOM Verification service for all applicable SOPs. Where the above requirements are not immediately available service providers must specify alternative solutions and timescales for meeting the above requirements. 115.1.4 It shall be the responsibility of the PACS service provider to confirm the DICOM interoperability of other vendors image acquisition equipment with the service and to identify any issues preventing full image and information sharing, in advance of planned interfacing to PACS. In the absence of suitable DICOM operability within certain image acquisition equipment, service providers shall provide DICOM gateways or suitable methods of image transmission to the service. The service provider shall provide as part of the response to this document a conformance table for all of its products in relation to the Integrated Health Enterprise (IHE) standard profiles and the date that these were tested and proven. Any development paths to aspects of HIPAA compliance relevant in the NHS shall be stated. The common user interface shall be clear, simple, flexible, and easy to use. General x -ray image acquisition units provided shall utilise DICOM Modality Worklist. In areas where more than one unit is in use, the provision of this functionality should not restrict staff in their choice of readers could be located in any units in a local area. It should also be possible to reallocate a worklist between units in different areas in case of breakdown.
Required Response
115.1.5
115.1.6
115.1.7 115.1.8
FINAL 1.0a
Page 261 of 607
ICRS
Requirement 115.1.9 DICOM worklist functionality shall be provided for all modalities. With existing non-DICOM equipment, the PACS supplier shall provide a solution. Service providers shall state their solution to the provision of DICOM worklist functionality for existing non-DICOM equipment. 115.1.10 Where the work of a part of the department is shared between 2 or more machines of different modalities, e.g. CT and cardiac catheterisation lab, it shall be possible to share a single worklist to allow maximum flexibility in patient allocation. PACS, including legacy solutions shall accept order details including the reason for the request, both electronically and by manual input from paper requests and display the details on acquisition worklists and specialist clinical users reporting worklists. The service provider shall provide the DICOM general purpose worklist facility to enable any reporting/ diagnostic workstation to DICOM query a request for a list of work items, rather than specific images. Service providers shall indicate proposed solutions for PACS accommodation of paper requests for examinations when PACS goes live. Service providers shall also state how the service manages this, including consideration of document scanning options. Local Milestones The service provider shall commit to achieving the implementation milestones specified in the PACS local data update to be issed separately for each cluster.
Required Response
115.1.11
115.1.12
115.1.13
115.1.14
Each bidder shall provide an indication of their commitment to achieve agreed milestones. Upon receipt of the local cluster data each bidder is expected to describe how they will achieve this requirement. The bidder must provide indicative costs and a full solution schematic with anticipated component breakdown for the mini-cluster model included in Section 115.9. The bidder will be provided with a local cluster data pack which will include details of the clinical evaluation process and details for local integation requirements..
115.1.15
Indicative Solution The functional components of the service shall be described in detail.
115.1.16
Local Evaluation The service provider shall be open to receipt of further local information per cluster to enable refinement of their proposed solution(s).
FINAL 1.0a
Page 262 of 607
ICRS
Requirement 115.2 Benefits and Outcomes The service provider shall deliver the benefits described above. 115.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans shall be agreed with each LSP.
Required Response Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Each bidder shall describe how it shall meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1.
115.3.1
The service provider shall include a detailed project plan for implementing their proposed solution for the mini-cluster model included in Section 115.9. Authoritys Responsibilities Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
115.4
FINAL 1.0a
Page 263 of 607
ICRS
Detailed Requirements Requirement 115.5 115.5.1 Digital Acquisition: General The service provider shall include the facility for computerised radiography with the appropriate digital capture equipment and print capability (e.g. laser, thermal, wax and others). The service provider shall allow fast visualisation of images after exposure at a clinical user's workstation and/or examination room to check for exposure and positioning etc. The service provider shall prioritisation of urgent images. support the Each bidder shall describe how the facilities shall be provided. Required Response
115.5.2
115.5.3
115.5.4
The service provider shall provide the means for temporary storage of processed images so that the service provider is not interrupted by downtime of either a section of a network or the archive. In case of network failure, the service shall have the capacity to store at least a weeks worth of patient images locally until repairs can be affected.
115.5.5
The service provider shall allow immediate access to relevant previous images and reports at the workstation and/or in the examination rooms at the time of scheduled examinations. The service provider shall be compliant with DICOM 3.0 standard (and its modality extensions) including DICOM Worklist, with all components being DICOM conformant and able to communicate using the DICOM standards. This includes the use of interfaces to existing modalities where required. Each bidder shall describe its position in relation to DICOM. The evaluation process shall include interoperability testing as described through IHE. Each bidder shall describe how it shall deliver future DICOM Service Classes.
115.5.6
115.5.7
The service provider shall support seamless links with all imaging modalities, initially within radiology (see 115.5.1 and 115.5.2 for other requirements). The service provider shall, where required for connection of older non-DICOM modalities to
Each bidder shall describe how this shall be achieved and how it shall accommodate non-DICOM image formats such as jpeg & tiff formats). Each bidder shall describe how this shall be achieved. Where applicable state how many ports are available on
115.5.8
FINAL 1.0a
Page 264 of 607
ICRS
Requirement the PACS, provide DICOM gateways. Software-based gateways are (requirement 115.5.9 in OBS1). 115.5.9 115.5.10 Moved to 115.5.8 The service provider shall allow the creation of CDs containing an image in a recognised PC format (e.g. jpeg, mpeg, avi, tif, DICOM) for the transfer of images. Any such images shall be accompanied by the relevant patient and image identifiers and diagnostic information. The service provider shall allow the creation of CDs containing an image in DICOM format, together with the software to view the image in a self-extracting file, for the transfer of images. The service provider shall capture and process non-DICOM outputs, including the relevant patient and image identifiers and diagnostic information. The services quality control functionality shall include measurement of mean amplitude and standard deviation of acquired image pixel values for user-specified regions. The service shall contain image annotation capabilities. The service provider shall provide arrangements for manual patient demographic data entry for patient identification, examination details and other DICOM header fields. This shall be required in the event of network/interface failure. It shall be possible to enter the DICOM accession numbers for the examinations. The service shall process images acquired during failure events in exactly the same way as images acquired normally, e.g. it shall be able to pre-fetch and route them. The vendor is responsible for ensuring that PACS interfaces with all image acquisition equipment that the Authority requires to be interfaced. Vendors shall agree to work with the Authority towards the future inclusion of non-radiological images. This shall include, though not be restricted to, retinal screening, endoscopy, image-related physiological waveform (e.g. acceptable
Required Response the DICOM gateway and whether there is a licence fee involved for connection to the gateway.
115.5.11
115.5.12
Each bidder shall describe how it this shall be achieved and how it shall acquire non-DICOM image formats.
115.5.13
115.5.14 115.5.15
115.5.16
115.5.17
FINAL 1.0a
Page 265 of 607
ICRS
Requirement ECG) recording, blood films, clinical photography, histology, pathology specimens, laparoscopic images, cytology and haematology images and shall include other clinical images captured graphically or photographically. Vendor to provide development path for the inclusion of images acquired outside radiology, whether these are originally acquired in DICOM or non-DICOM format. The vendor shall state any limitations in the acquisition of non-DICOM images. 115.5.18 115.5.19 Image routing from a modality configurable by approved users. shall be
Required Response
For modalities that produce colour images the service shall be able to acquire, store and display colour images and if necessary display these images in greyscale on black and white display devices. The service shall display a warning if a colour image is displayed on a black and white device. Images produced by post processing after an examination is completed (e.g. 3D reformats), shall be able to be stored within the patient study containing the original images. From non-DICOM digital modalities, it shall be possible to take demographic data and integrate this to the services database(s) with minimal operator intervention. Where measurements or other image annotations have been applied to an image, these shall also be stored and associated with that image and made available for review. The user shall be able to display images without annotations, if required. The service shall allow DICOM compliant images on removable media to be imported, viewed on workstations and stored in the PACS image archive. The service shall handle and process any images/examinations that are transferred to permanent storage in exactly the same way as images captured from local modalities, e.g. the service shall be able to prefetch and route them. Acquisition of such images to the service to be performed by approved users only.
115.5.20
115.5.21
115.5.22
115.5.23
FINAL 1.0a
Page 266 of 607
ICRS
Requirement 115.5.24 The service shall provide the facility for the storage of rejected images in a folder where they are available to authorised users for the purposes of reject analysis. It shall be possible for authorised users to select and display images that have been rejected because of poor quality, or images taken for quality control purposes. The rejecting user ID and the reason for rejection shall be stored with the rejected image. Approved users to be able to unreject images. Service providers shall give details of how the audit trail for rejection and unrejection is handled. The operator shall be able to add, edit or delete examination details at the workstation, e.g. in case of data entry errors. Details of any altered examinations shall be communicated to any external systems that may require the information (e.g. specialty information solution (in the case of radiology, commonly referred to as a RIS)). They shall also have the ability to mark images as rejected following capture. All images shall then be relayed to the PACS for storage in the patients folder. Display devices shall be linked to the general x-ray image acquisition device and digitiser equipment to allow immediate access to viewing the image. After image read-out, the CR plate or DR image receptor shall be sufficiently erased that any residual image cannot be detected by a specialist clinical user viewing the next or subsequent clinical images. The service shall contain a facility to log interventions that have altered images. This log shall be accessible at the diagnostic terminals. Ability to view this log to be available to approved users only. The service provider shall provide costs and proof of validation for interfacing modalities with PACS and from this information individual Authorities can reach a decision on whether to interface each machine. Service providers shall specify in advance what is required to interface each machine. The service provider shall state how they shall manage future modalities with large amounts of images or video data, DICOM and nonDICOM sources. The service provider shall supply information
Required Response
115.5.25
115.5.26
115.5.27
115.5.28
115.5.29
115.5.30
115.5.31
FINAL 1.0a
Page 267 of 607
ICRS
Requirement on a range of options to avoid transcription / input errors and enhance workflow, such as barcodes and magnetic card reading for the entry of demographic data. X-ray image acquisition requirements: general 115.5.32 devices
Required Response
Where CR units are to be provided, the plates shall be supplied with the following minimum resolution of the final image: Standard spatial resolution: 2.5 lp/mm (All sizes). High spatial resolution: 5 lp/mm as measured using the Huttner type 18 method.
115.5.33 115.5.34
In general x-ray, the image data shall be acquired at a minimum of 12 bits/pixel. It shall be possible for the operator to review previous images belonging to a patient (and stored in the central storage unit) at any point during the examination. This facility shall be provided in the immediate area of the CR units. The CR readers shall perform regular selfdiagnostic checks sufficient to maintain contracted performance standards and report any error or fault conditions to the operator. Errors during clinical use of CR units shall be indicated immediately to the operator. The service shall support mammography imaging by utilisation of CR and/or DR modalities. The service shall support full leg length imaging by utilisation of CR and/or DR modalities (e.g. equivalent image size of a 43cm x 105cm film). The service shall support full length spinal imaging by utilisation of CR and/or DR modalities. The service provider shall supply sufficient acquisition devices, ID workstations, image processing workstations etc. such that the current workload and work practices of the departments are maintained or enhanced.
115.5.35
115.5.36
115.5.37
115.5.38
115.5.39
FINAL 1.0a
Page 268 of 607
ICRS
Requirement 115.5.40 In high throughput areas, where CR units are provided they shall allow stacking of plates of various sizes per unit (both before and after processing) and the facility to change the sequence of the plates in the stack before processing. Service providers shall provide an analysis of this facility. After image capture the CR device shall display the patient identity, examination number, date and time of the examination and allow free text and anatomical identifiers to be entered by the operator to be associated with the image. In case of network failure, all general x-ray image acquisition systems shall automatically store (including storage to removable media) and print images locally and/or display the images on local diagnostic quality workstations until repairs can be effected. Image transfer shall be achieved such that the timing of ongoing image acquisition is not adversely affected, i.e. transfer can be achieved in the background without slowing ongoing patient examinations. All CR units shall support user defined and automatic image processing, before transmission of the image to the PACS network. Functions shall include blackened surround, contrast enhancement and reverse contrast scale, edge enhancement and unsharp masking. Details of processing shall be communicated to the network and stored in the image database with other data associated with each image, which shall include pixel size (mm per pixel at the plate). Where CR units are provided, exposed image plates shall retain the image for up to six hours without observable loss of image quality. The signal on the phosphor plate shall not decay within twelve hours beyond 70% of its initial level on initial acquisition, under standard ambient and usage conditions. 115.5.46 The service offered shall not result in an increased average patient radiation dose. Preferably the dose shall be less than that required for conventional radiography.
Required Response
115.5.41
115.5.42
115.5.43
115.5.44
115.5.45
FINAL 1.0a
Page 269 of 607
ICRS
Requirement 115.5.47 The service provider shall include facilities for quality assurance and describe the features that allow the users to monitor the performance of the CR system. For all general x-ray image acquisition devices, the service provider shall state the number of 35cm x 43cm (or equivalent) images acquired per hour. Where CR is provided, the service provider shall state the guaranteed minimum lifespan of plates in terms of years and exposure cycles, including how this is calculated. The service provider shall provide graphs of detective quantum efficiency (DQE) against spatial frequency for each image acquisition device and for an appropriate range of exposure values. Please state in each case the radiation quality (kV and HVL) at which the DQE was measured. The service provider shall state the dynamic range for each combination of CR reader/CR plate/pixel size/plate type. The service provider shall provide a graph demonstrating latent image decay against time for the CR plates proposed. The service provider shall provide a plot of modulation transfer function (MTF) against spatial frequency for each combination of CR reader/CR plate/pixel size/plate types. Image digitisation requirements: detailed 115.5.54 At the time of digitisation the service shall allow the user to enter the examination type, time and date of the study onto the PACS/specialty information solution (in the case of radiology, commonly referred to as a RIS) database. The service shall ensure that the study date is the actual date of the original study and not the date of digitising the exam, which shall also be recorded. Digitisation shall allow a minimum range of spatial resolution from 2.5 lp/mm to at least 5 lp/mm. Spot size per pixel should be less than 0.175mm. All images shall be digitised to minimum 12-bit depth, with all bits being stored. Film digitiser(s) shall support as a minimum the following film sizes (cm): 35x43
Required Response
115.5.48
115.5.49
115.5.50
115.5.51
115.5.52
115.5.53
115.5.55
115.5.56
FINAL 1.0a
Page 270 of 607
ICRS
Requirement 35x35 30x40 24x30 18x24 18x 43
Required Response
15x30 Sites may require a scanner to scan hard copies for inclusion in PACS. It is not intended that the complete backlog of hard copies be included in PACS. The service provider shall investigate which sites own scanners and which require them. 115.5.57 The PACS shall accommodate the digitising of films of specialisations such as dental, and mammography. The service shall provide the following software functionality f r control of digitisation o parameters: Selection of image resolution. Look-up-table (LUT) transformations. Image rotation/re-orientation. Spatial filtering image cropping. Window width and level setting.
115.5.58
The parameters should be set as default for subsequent display. 115.5.59 The service shall contain the facility for user selectable image output formats from all digitisers. These shall be DICOM compliant and shall accommodate JPEG & TIFF formats. The service provider shall provide digitizers that are DICOM conformant and appropriate to the indicated workload and pattern. For small matrix images such as CT, MR, nuclear medicine, digital fluorography, digital angiography and ultrasound, each individual image shall be digitised to a matrix at least the size of the original image. The service shall be capable of digitising optical densities between 0.1 and 3.6. The service requires a 60-second per film maximum film scan speed. The time is measured from the beginning of any required operator interaction with the digitiser, until the image is displayed ready for manipulation/dispatch to PACS. The digitiser system shall support temporary
115.5.60
115.5.61
115.5.62 115.5.63
115.5.64
FINAL 1.0a
Page 271 of 607
ICRS
Requirement local storage, per Authority, for at least 200 films of size 35x43, uncompressed at maximum depth, with capability for onward transmission into PACS. 115.5.65 The service shall support the ability to digitise paper documents (i.e. request forms, consent forms, reports, vascular ultrasound diagrammatic reports) and associate them with the appropriate examination. The digitiser system shall support connection to each Authority's patient database to allow association of patient data with an image without manual entry of patient demographics. There shall be support for DICOM Modality Worklists. The service shall support association of the same patient data with multiple films, allowing multiple digitised images to be combined as a study. The service shall provide the facility for the loading of multiple films of mixed sizes for automatic processing. The digitiser shall recognise the film size and only digitise this area. The service shall be able to auto-size the displayed image. After digitising hard copies of images, the individual images shall be able to be viewed in a stack in the same way that digitally captured images are viewed. The service provider shall provide the MTF of the digitiser and the curves that relate optical density to digitised signal at each digitised pixel size. Curves should also be provided which show the digitiser noise as a function of optical density or digitised signal magnitude at each pixel size. The service provider shall state the specification of digitiser system that shall be required to support digital mammography. PACS archive requirements The service provider shall include the archive facilities required for the safe and efficient handling of all images. The archive shall be robust to prevent the tampering with images or the deletion of them. Storage shall be configured such that access to images produced in the recent past is
Required Response
115.5.66
115.5.67
115.5.68
115.5.69
115.5.70
115.5.71
115.5.72
115.6 115.6.1
115.6.2
FINAL 1.0a
Page 272 of 607
ICRS
Requirement immediate and images from attendance over the previous two to three years can be retrieved in a reasonable time span without manual intervention. Retrieval is required for all images to predetermined locations and workstations at specified times i.e. images shall be available when and where required. 115.6.3 The service provider shall ensure no loss or corruption of images and guarantee that there shall be no distortion or degradation of the data as a result of the transmission process. The service provider shall be fully upgradeable and expandable to continue to meet the future requirements and to make best use of technological improvements and cost reductions. The service provider shall provide appropriate facilities to enable radiology reporting to be carried out and stored within the image management system environment, if required and allow for viewing both current images and previous images with their verified reports. The service provider shall enable the inclusion of images on the archive other than radiological images e.g. photographs, scanned images and video images. The service provider shall be able to deal with case note extensions and be able to differentiate between all other forms of media format, including: Photographs. Video. X-rays. Sound files. Multimedia files. Various equipment. outputs from medical
Required Response
115.6.4
115.6.5
115.6.6
115.6.7
All types of document typically found in paper-based clinical records. Reformatted or reprocessed images. Digital image storage requirements 115.6.8 The service shall provide an archiving facility that accommodates a PACS index with a unique patient identifier. This identifier should be the NHS number or should at least map
FINAL 1.0a
Page 273 of 607
ICRS
Requirement directly to the NHS number. 115.6.9 The storage system shall monitor usage and provide real-time display of usage patterns and statistics. This data is to be available to approved users only. The service provider is responsible for ensuring that PACS interfaces with all image storage and retrieval equipment. The service provider shall commit to check that the Authority networks and connections are satisfactory to deliver the performance described in 4.3 Solution Requirements. The service provider shall be required to state if any changes are needed to Authority networks. The service shall support DICOM conformant lossless compression of images for transfer purposes. The service provider shall supply a scalable archive and shall indicate how capacity can be increased in the future, including increases in capacity beyond those initially antipcipated. The service provider is required to detail their approach to redundancy in case of failure of storage and/or database systems. The service shall tolerate hardware failure without loss of data and remain operational. Images that are entered into the image store shall not be deleted at any time thereafter. The service shall make examinations available for retrieval immediately after the receipt of the image in the storage system. The service provider shall state the maximum delay. The service shall allow images to be stored using various levels of compression, both lossless, and lossy. The choice of whether to use lossy compression and what degree of compression, shall be under the control of authorised users and shall be configurable by type of examination (modality and body part). Details of the compression algorithms and validation of claims for lossless compression, shall be given in the response to this document.
Required Response
115.6.10
115.6.11
115.6.12
115.6.13
The bidder must indicate whether such storage may be interfaced using industry standard techniques such as SCSI, NAS, SAN, etc.
115.6.14
115.6.15 115.6.16
115.6.17
FINAL 1.0a
Page 274 of 607
ICRS
Requirement 115.6.18 All examinations have a unique accession number. The service provider shall show that they can provide a solution that can accommodate multiple images for a procedure and assign each image a unique ID. In addition, the service provider shall give information on how they shall handle the multiple specialty information solutions (in the case of radiology, commonly referred to as a RIS), or the equivalent, held by the different Authorities/sites within a typical cluster; notably the issues of multiple exam numbers, location codes, referral codes etc. The service shall allow for the retrieval of images through classifications set up by users. Once an image has been quality assured it shall not be able to be altered in PACS storage. The service provider shall demonstrate the scalability of their solution. The service shall have the facility to retrieve and store any images stored in modality or other legacy databases. The service provider shall state how it shall take on images stored in legacy databases, including the management of private tags (and proprietary metadata). The service provider is required to describe the typical image data model of storage proposed, with the media and capacity of individual devices specified. Devices include individual workstations, RAID array, discs/tapes, servers etc. In addition the service provider shall describe data flows including timing of storage and transfers. The service provider shall provide details of the methodology for calculations undertaken in sizing the archive. The service provider shall describe their approach to provisions for archive growth and scalability. Responsible specialist clinical user and specialistclinical user image viewing The service provider shall provide responsible specialist clinical user and specialist clinical users with reporting workstations. It shall be possible to configure workstations to customise the desktop for different radiology users.
Required Response
115.6.19 115.6.20
115.6.21 115.6.22
Service providers are required to provide details of the methodology and examples.
115.6.23
115.6.24
115.7
115.7.1
FINAL 1.0a
Page 275 of 607
ICRS
Requirement 115.7.2 The service provider shall ensure that the clinical history associated with an imaging examination is visible to the specialist clinical user on the PACS workstation at the time of reporting of the associated images. The service provider shall enable an urgent image to be processed without losing other images which are also being processed. The service provider shall enable images on separate plates to be joined together seamlessly, whilst retaining the separate identities of the individual images. The service provider shall supply a system tool whereby measurement of distances and angles may be regularly checked against a test image. Any factors that have to be applied to correct for different systems or images shall be recorded and readily available. Image retrieval 115.7.6 It shall be possible to select a single examination or selection of exams for reporting. It shall be possible to organise examinations ready for reporting into user definable worklists, to include: Unreported inpatients, outpatients, A&E or other type designated by the specialty information solution (in the case of radiology, commonly referred to as a RIS). Modality type. Ward. Referring clinician. Specific specialist clinical user.
Required Response
115.7.3
115.7.4
115.7.5
115.7.7
Date or range of dates (or older than). Or any combination of the above. The service shall allow configurable worklists. 115.7.8 approved user
The service shall have user definable worklist wizards enabling preset worklist configurations.
FINAL 1.0a
Page 276 of 607
ICRS
Requirement 115.7.9 115.7.10 It shall be possible to route worklists between workstations. When reporting a selection of examinations, completion of the process for the first and subsequent exams shall automatically trigger display of the next exam. It shall be possible to incorporate user definable relevant previous images within a worklist. It shall be possible to retrieve and display as a single list an entire patients imaging record including previous images and corresponding requests and reports. While viewing an image it shall be possible to retrieve ad hoc previous images for the same patient. Subject to optimum network performance, service providers shall state the minimum and maximum time delays expected for image retrieval for all of the image data repositories within the service: For example: 115.7.15 Short term workstation Long term workstation storage archive to to diagnostic diagnostic
Required Response
115.7.11
115.7.12
115.7.13
115.7.14
Web based storage archive to web based clinician workstation Short term archive to web based archive.
Image search criteria shall be user configurable in terms of displayed options and shall include as a minimum: Basic demographics: name, hospital number(s), NHS Number, date of birth Unique examination number (accession number) Date and time of examination Examination type Modality Body part Referral information Referring Clinician Patient Location Patient type (e.g. in-patient).
FINAL 1.0a
Page 277 of 607
ICRS
Requirement 115.7.16 It shall be possible to display all of a patients images, within a single file, without leaving the image display screen. It shall be possible to retrieve relevant prior images via user definable criteria. It shall be possible to sort patients on the workstation into worklists based on modality, body part, examination date, specialist clinical user code and patient source (e.g. GP, inpatient) etc. for the purposes of reporting with the facility to mark studies as read or unread. Selection of patients from worklists and selection of manipulation tools, next patient, next study etc. shall be by means of a single mouse click or a simple keyboard shortcut. Worklists shall be sortable by name, study date or radiology number to facilitate reporting sessions driven by request forms. It shall be possible to sort by unread studies. Reporting specialist clinical users shall be able to report from worklists without interruption by incoming studies. It shall be possible to search the database for image retrieval by at least the following fields, or combination of the following: 115.7.24 Name Hospital number Modality Date of examination Ward or other patient location Sex Body part Examination status Source of referral (outpatient, inpatient, GP and named referring physician) Date of birth Accession number.
Required Response
115.7.17 115.7.18
115.7.19
115.7.20
115.7.21 115.7.22
115.7.23
For the service provided, all examinations shall be accessible from every workstation, limited only by security mechanisms. It shall be possible to request old examinations from the long term archive.
115.7.25
FINAL 1.0a
Page 278 of 607
ICRS
Requirement 115.7.26 A clinical folder shall be automatically created for each patient referencing all his/her examinations. The most recent examinations shall be automatically included in this folder. Service providers shall provide the criteria they use in meeting this requirement. It shall be possible to view a list of all examinations for a particular patient and that patient only. It shall be possible to further refine this list, for example by most recent examinations. 115.7.27 Automatic retrieval of associated previous images shall be available. This shall be configurable by user, modality and body part for retrieval of relevant priors. A user with the proper privileges shall be able to add or remove selected images to or from the clinical folder. There shall be a mechanism for prompting a specialist clinical user to sign off a study as read before proceeding to the next patient in order to prevent double reporting of studies. The service shall allow users to display a list of examinations based on queries of patient name, ID, location, age (in user definable ranges), modality, exam status, specialist clinical user, date and time of acquisition, requesting physician, patient category and most recent prior acquisition of the same body part or any specialty information solution (in the case of radiology, commonly referred to as a RIS) field that is mapped. New reporting worklists shall be definable according to specialist clinical user, modality or workstation, or other criteria, at any time by the on-site administrator. The reporting worklists available to a user shall be those assigned to the user, plus those assigned to the group of which the user is a member, plus those assigned to the workstation at which the user is working. The workstation shall support manually rearranging the sequence of images in an examination.
Required Response
115.7.28
115.7.29
115.7.30
115.7.31
115.7.32
115.7.33
FINAL 1.0a
Page 279 of 607
ICRS
Requirement 115.7.34 The service shall provide user-selectable, user-definable default display protocols for display of the images of an examination where the protocols are specific to the type of examination. The intent of this requirement is to allow physicians preferences for display to be satisfied. Images shall be automatically presented in an upright as well as correct right/left orientation whenever the image orientation is known to the service and the orientation is not overridden by a display protocol. The workstation shall allow a user with the proper privileges to save the information that controls the display of the images of an examination, including window width and level, display sequence, orientation, magnification, pan position, and any annotations. Only the most recently saved display state need be saved, although storage of intermediate steps may be provided. Please describe the way in which the offered solution deals with this. If an examination is displayed which has had its display state saved, that display state shall be used. The workstation shall support the display of multiple examinations simultaneously. The service shall provide user-selectable, user-definable protocols for display of multiple examinations where the protocols are specific to the types of examinations being displayed together. The intention of this requirement is to support the presentation of historical studies along with a new study for diagnosis. The service shall enable rapid movement to the next or previous examination in a reporting worklist. The intent of this requirement is to allow the specialist clinical user to close a currently open examination and open the next one in a worklist with the equivalent of one keystroke. The service shall enable rapid movement to the next or previous patient in a reporting worklist. The intention of this requirement is to allow the specialist clinical user to close a currently open examination and move to the next patient in a worklist with the equivalent of one keystroke.
Required Response
115.7.35
115.7.36
115.7.37
115.7.38
115.7.38 115.7.39
115.7.40
115.7.41
FINAL 1.0a
Page 280 of 607
ICRS
Requirement 115.8 115.8.1 Clinical user image viewing The service provider shall provide facilities for general clinical users to retrieve and access PACS images. The service provider shall support immediate image access on all workstations, so that reporting can take place on any workstation without the need to preload images. The service provider shall allow primary readers (specialist clinical users, cardiologists etc.) to have simultaneous access and full cooperative working with the referring physician, using annotations and/or a shared cursor. The service provider shall be capable of providing graphical interpretation/presentation of information; e.g. nuclear medicine renograms. Sequential images shall be viewable across multiple monitors. The service provider shall include a common search tool which is user-configurable to access images produced on any Authority site. The service provider shall support data entry through user-defined pick-lists and coded entries where appropriate and interface with DICOM equipment work lists for results and image processing. The service provider shall support production of a hard copy of any image in the archive. The service provider shall record when an image is accessed, and this shall be written to a searchable Audit Trail. The service provider shall be able to record the patient's consent for their images to be used for some or all of the following: treatment, research, education, audit, teaching etc. It shall be possible to convert existing images and archives onto the service where these are already in a DICOM format or are contained inside a DICOM wrapper. The service provider shall provide a facility for the receipt and transmission of images,
Required Response
115.8.2
115.8.3
115.8.4
115.8.5
115.8.6
115.8.7
115.8.8
115.8.9
115.8.10
115.8.11
FINAL 1.0a
Page 281 of 607
ICRS
Requirement complete with necessary identifiers, to and from other health care providers and other sources/destinations. 115.8.12 It shall be possible to transmit images in a secure manner to any location supported by dial-up access e.g. to specialist clinical users' homes (see also the standards and policies section). Users shall be able to observe a patients previous imaging record as a single entity but also be able to interrogate this "folder" from a number of different perspectives e.g. by anatomical part, by modality, or by the Authority at which the images were created. The service provider shall link with current and new RISs to allow a single transfer point for patient demographics, requests and reports. The interaction between RIS, Patient Record and PACS systems shall ensure the creation of unique and identifiable events, matching images to reports and current to previous patient encounters. The links shall provide for updating, merging, searching and creating records, in addition to functions that assist with the management of that data and its presentation and interrogation, where and when required for clinics; e.g., for reporting. The use of templates for prostheses shall be included.
Required Response
115.8.13
115.8.14
115.8.15
Each bidder shall describe how this shall be achieved and give details of their current templates for prostheses. Each bidder shall describe how this shall be achieved.
115.8.16
The service provider shall be able to pre-fetch image lists using links to the RIS or Patient Record as necessary. Image Display
115.8.17
PACS shall be accessible from multiple web servers allowing image review on different versions of web browsers. Service providers shall specify which browsers (including version information) are supported and their policy with respect to support of future browser versions. There shall be a common user interface across all elements of the PACS. The service shall accommodate the display of images with enough information to allow quick identification e.g. patient ID, modality, study date and time, kVp, mAs, slice position. There
115.8.18 115.8.19
FINAL 1.0a
Page 282 of 607
ICRS
Requirement shall also be the facility for this information to be removed from the display if required, to reduce clutter, maximise image-viewing area and for the purpose of confidentiality of patient data within conference/teaching environments. Where it is necessary to display all image header information this facility shall be provided. If images have associated annotations then these shall be optionally displayable. 115.8.20 The cursor shall move within and between display devices in a smooth and continuous manner under the control of a mouse or trackball-pointing device, with the cursor remaining visible during its movement. The service shall support user selection of the display location of an image on the display device(s). The service shall support multiple image display, in real time, on single and/or multiple display devices for images from single and/or multiple examinations. There shall be the ability for multiple exam modality types to be displayed simultaneously e.g. CT, MRI. The administrative status of any report, (e.g. if it is unverified) shall be indicated when the report is displayed. It shall be possible to choose among multiple display formats for the display devices of a workstation. E.g. 1:1, 2:1, 4:1, 6:1, 9:1, 12:1, 15:1, 20:1. The workstation shall have stack mode functionality to support arranging groups of related images into a stack (only the top image visible) and display them sequentially forward or backward, commanded by movement of the workstations pointing device. This shall allow users to review multiple sequences from the same examination and to review sequences from separate examinations synchronised together. Reports of the displayed examination or a previous examination shall be available via the user interface, by means of a single mouse click or equivalent. Feedback mechanisms shall be present whereby any errors of function are reported immediately to the user.
Required Response
115.8.21
115.8.22
115.8.23
115.8.24
115.8.25
115.8.26
115.8.27
115.8.28
FINAL 1.0a
Page 283 of 607
ICRS
Requirement 115.8.29 It shall be possible to perform interactive greyscale adjustment on displayed images in real-time, either individually or altogether. The service shall contain an image magnification facility allowing full resolution display of all or part of the image. The workstation shall be capable of enlarging an image up to at least 4x by replication of pixel values. The workstation shall be capable of enlarging an image up to at least 4x by interpolation of pixel values. It shall be possible to zoom a single image, selected images or all images in one operation. Zoomed images shall be capable of repositioning by panning (roaming) the image within the area allocated for display of the image. When the actual image size is greater than the display device resolution or the resolution of the available display window, it shall be possible to reposition (pan) the image in the window dynamically and interactively. When the actual image size is greater than the display device resolution or the resolution of the available display window, it shall be possible to map the image to the display area by sub-sampling. The intention of this requirement is to assure that, for example, a CR image can be minified to fit on a 1k display device to provide an overview. Specific minification commands in addition to a fit-towindow command (e.g. minify by one-half etc.), while not required, are acceptable. When zooming an image, the original image dataset shall be used. The intent of this requirement is to assure that zooming a minified image shall provide additional resolution up to that of the originally acquired image.
Required Response
115.8.30
115.8.31
115.8.32
115.8.33
115.8.34
115.8.35
115.8.36
115.8.37
FINAL 1.0a
Page 284 of 607
ICRS
Requirement 115.8.38 The workstation shall include a user-sizeable magnifying glass function which supports the options of variable magnification up to at least 4x, internal window width and level, and greyscale inversion. When applying the magnifying glass to an image, the original image dataset shall be used. The intent of this requirement is to assure that magnifications of a minified image shall provide additional resolution up to that of the originally acquired image. The service shall allow the user to select a range of grey-scale look-up tables, including reverse video and colour display look-up tables where appropriate for colour display devices. The service shall provide DICOM grey scale display function with calibration procedure to enable standardisation of luminance on dedicated workstations and printers. The service shall have the facility for continuous zoom. This is achieved by redisplay from the original image. When displaying images that have more pixels than the displays, the workstation shall also have a minification function that sub-samples the image so that the entire image appears to fit on the display. The service shall accommodate measurements of length, angle, area, volume and perimeter and allow calibration with reference to measurements. The Service shall accommodate up to 4 measurements simultaneously. The service shall provide image flip and rotate functionality. There shall be a user identifiable display to show if and how the image has been manipulated in this manner. The service shall allow display of image size in 1:1 pixel ratio to size at acquisition (CR only). The service shall provide the facility to construct folders that contain images from multiple patients in the same folder.
Required Response
115.8.39
115.8.40
115.8.41
115.8.42
115.8.43
115.8.44
115.8.45 115.8.46
FINAL 1.0a
Page 285 of 607
ICRS
Requirement 115.8.47 If images are received from a modality along with window width and level for viewing, these shall be used for initial display on the workstation. If an image is displayed for which no window width and level is available, the workstation shall select a set of values that allow the image to be visualised. If no display protocol exists for a specific user and examination type, the service shall provide a default protocol. Authorised users shall be able to reset the stored values for window width and level for subsequent default display of any given image or set of images without changing the original image data as stored on the archive. Default display protocols shall be definable by users in relation to study type, study group, anatomical region, view, which classes of workstation can support them and other criteria. Default display protocols shall be activated by the user name at logon. Pre-set window widths and levels (to be user defined) shall be readily available to users and these can be reset to the default window by a single key stroke. The service shall provide a mechanism for automatic log-off of a user at a workstation after a configurable period of workstation inactivity. Any work in progress to be reset to its previous state, e.g. an examination being reported shall be closed and made available to other users for reporting. The impact of this functionality on the ability to park a partially completed report shall be described. The service shall accommodate the functionality to support multi-disciplinary team meetings at a variety of sites. Images to be viewed in these meetings shall be stored in clinical folders (i.e. a grouping of images and reports from different examinations for the same patient). A user with the proper privileges shall be able to add or remove selected images from the clinical folder. If a specialist clinical user displays an unreported examination, then this examination shall be made available for viewing but unavailable for reporting by another specialist clinical user and the second viewer shall be made aware that the examination is already being viewed.
Required Response
115.8.48
115.8.49
115.8.50
115.8.51
115.8.52
115.8.53
115.8.54
FINAL 1.0a
Page 286 of 607
ICRS
Requirement 115.8.55 The workstation shall allow authorised users to display the report for any reported examination with or without display of its associated images. The service shall allow for the textual and graphical annotation of images by authorised users. The service provider shall describe how they achieve easy and intuitive ways of entering annotations onto images in PACS. The service shall have cine-mode functionality with variable frame rate. A minimum frame rate of 10 frames per second for a 512x512 image. The user shall be able to run cine mode for synchronized examinations. The service shall have a cancel facility whenever time consuming operations are in progress, the workstation shall indicate to the user that it is working and provide a way to cancel. The service shall have a privacy function (e.g. a screen saver). This shall be configurable by workstation and by an authorised user. There shall be the capacity for dynamic review of 3D re-formatted images, e.g. virtual endoscopy imaging. There shall be accurate measurements of lengths, angles and arcs for treatment planning and image annotation which shall be retained for display at a later date. There shall be the ability to measure Hounsfield values over a defined area and also the ability to measure the Hounsfield value of a single pixel. There shall be software to facilitate use of virtual templates for prosthetic devices as part of treatment planning. The service shall support keyboard shortcuts in order to access image manipulation tools such as zoom and windowing. All images shall be available for viewing whether or not they have been reported, but individual Authoritys solution managers shall control the functionality for this. The service shall support the display of image related data captured at the modality e.g. obstetric ultrasound images or CT pelvimetry.
Required Response
115.8.56
115.8.57
115.8.58
115.8.59
115.8.60
115.8.61
115.8.62
115.8.63
115.8.64
115.8.65
115.8.66
115.8.67
FINAL 1.0a
Page 287 of 607
ICRS
Requirement 115.8.68 The service shall be compatible with the screen projection facilities required across the Authority, both existing and planned. Please state the resolutions of any proposed projectors. The service shall allow for the display of the pixel value at the position of the cursor, profiles of pixel values and the mean and standard deviation of the pixel values in selected regions of interest. The workstation shall provide an interrupt facility. For example, when an arrangement of images has been established by a user and the user is then interrupted by a colleague wanting to view a different examination as a matter of urgency, that the initial arrangement can be reproduced with a minimum of keystrokes/ interactions. The service shall have a context sensitive online help or similar mechanism to facilitate user operation and correction of errors of use. This shall be demonstrated in a clinical environment. The Service shall have a configurable undo facility allowing retraction of the last action requested by the user, cancel, pause and solution working indicator. The system administrator to control exactly which functions can be undone. Authorised users shall be able to flag images and/or reports as confidential so that they can only be viewed by named users or specified user groups. The service shall allow voice recognition Software for application command functions and the entry of text annotations. Service providers shall provide the timescale for delivery of this functionality. The service shall contain the facility to view angiography (both cardiac and non-cardiac), cine, CT and ultrasound images as moving images in "real-time" in a specified number of locations. Users shall have the ability to run user definable macros to enable quick searches of the service for searches that shall be repeated frequently. The date display shall be in the standard UK format i.e. day-month-year: dd-mm-yyyy.
Required Response
115.8.69
115.8.70
115.8.71
115.8.72
115.8.73
115.8.74
115.8.75
115.8.77
115.8.78
FINAL 1.0a
Page 288 of 607
ICRS
Requirement 115.8.79 115.8.80 The service shall support multiple display device access through web browsers. There shall be a conferencing facility available between workstations where one workstation shows the cursor of another user on a different workstation. This facility shall be available between workstations located within different Authorities. The service shall display image thumbnails by default protocol. Scout views for digital modalities shall be available and shall be dynamic. The workstations shall provide the following functions by a single click on the mouse or keystroke access, customisable by modality and/or user: Pictorial image directory (e.g. thumbnail images or icons) Access to radiological reports Access to clinical details (via scanned request forms or electronic order communications) Digital voice dictation Voice recognition software for reporting\approval of reports on PACS with messaging to the specialty information system.
Required Response
115.8.81 115.8.82 115.8.83
The bidder shall for each of the specific requirements supply a matrix table showing which of the features and functions can be used on which type of workstation (diagnostic, QA, clinical review and web). Additionally, the bidder shall state any limitations or special requirements of these workstations.
115.8.84
Considerable importance is attached to the ease of use of the service as a whole. The service provider shall describe its approach to such issues and highlight relevant features. The service provider may wish to break this information down by staff group or equipment category. The service provider shall give information on the minimum specifications for equipment to display images from the service. The service provider shall state the full range of image analysis tools that are available on the service. Service providers shall list which prosthesis manufacturers their solution can support. Service providers shall indicate every possible display type and configuration that they shall supply and/or support. service providers shall include a full description with technical specifications and indicative costs.
115.8.85
115.8.86
115.8.87 115.8.88
FINAL 1.0a
Page 289 of 607
ICRS
Requirement PACS hard copying 115.8.89 The service provider shall provide networked printers to support the needs of the department for hard copy production and to provide one possible mechanism of image production and distribution in the case of partial solution failure. The service shall provide the facility for the printing of images displayed on workstation via local or shared paper printers. The service shall incorporate printers that are capable of a variety of image formats, e.g. 1:1, 2:1, 4:1, 6:1, 9:1, 12:1, 16:1, and 20:1. The hard copy solution shall be capable of printing images at a variety of different sizes. State available sizes. The service provider shall state how the printing of images impacts on the rest of the service. The printer output shall conform to DICOM greyscale display function (hard copy output). The service shall produce diagnostic quality hard copies of images, including mammography where appropriate. In order to facilitate continued working during a period of network malfunction, sufficient printers shall be portable so as to be capable of being moved to the location of any chosen modality for direct connection. All hard copy devices shall operate in an environment where they do not use any substances hazardous to health (COSHH-free environment). The service provider is responsible for ensuring that PACS interfaces with all compatible printing equipment already in use in the Authorities. The service provider shall supply a list of any of the current printing equipment that they cannot support. It shall be possible to hard copy clinical images at their actual size for plain radiography. It shall also be possible to print magnified and reduced images. The service shall provide a facility to allow system administrators to allocate permissions for the production of hard copy to authorised users.
Required Response
115.8.90
115.8.91
115.8.92
115.8.93
115.8.94 115.8.95
115.8.96
115.8.97
115.8.98
115.8.99
115.8.100
FINAL 1.0a
Page 290 of 607
ICRS
Requirement 115.8.101 The service provider shall provide a mechanism for monitoring hard copy performance. There shall be the option, when printing hard copies to remove overlays such as demographic data before printing films. There shall be the facility to burn images onto CD and/or DVD in DICOM format and include DICOM viewer software on the disc. Networked film printers and processors shall be required for the duration of an agreed implementation and changeover period. This is necessary to support the production of hard copy. The service provider is required to indicate how this might be achieved with consideration being given to existing facilities within all the Authorities/sites. PACS with teleradiology 115.8.105 115.8.106 The service shall support user selectable data compression (both reversible and irreversible). The type and level of compression shall be displayed along with images when they are displayed. The service shall support the use of different file formats e.g. DICOM, jpeg, and TIFF for import and export. The service shall support the transfer of patient images and data to and from remote sites. It shall be possible to transfer a single file to multiple user-specified destinations across all participating Authorities. The facility to transfer selected images/examinations to permanent storage within PACS shall be available to appropriately authorised users. The service shall handle and process any images/examinations that are transferred to permanent storage in exactly the same way as images are captured from local modalities; e.g. the service shall be able to pre-fetch and route them. The service shall be capable of managing multiple simultaneous requests for import/export in such a way that no data is lost and if delays to export are expected to be more than 5 minutes, the operator shall be notified.
Required Response
115.8.102
115.8.103
115.8.104
115.8.107
115.8.108
115.8.109
115.8.110
115.8.111
FINAL 1.0a
Page 291 of 607
ICRS
Requirement 115.8.112 Selection of images for export via the service shall be possible on a patient, image, examination, folder, or similar basis. The transmission system shall have adequate error checking capability such that there is no loss of information in transit. The service shall notify the operator of any errors detected. The facility to alter solution priorities shall be available to authorised users. The service shall store incoming images and make them available via PACS to authorised users. The facility to send and receive text with images is required. The service shall provide information on status, workflow, queues etc. to authorised users. It shall be possible to monitor the progress of requested transfers in "real time". All such information shall also be made available for analysis if required. Failure to complete an import shall be notified immediately to the service administrator and sender. The facility to export images from any workstation on the network by an authorised person is desirable. Teleradiology shall be accessible from a multitude of platforms.
Required Response
115.8.113
115.8.114 115.8.115 115.8.116
115.8.117 115.8.118
115.8.119
115.8.120
115.8.121
Bidders are requested do describe their position with respect to the highly distributed use of PACS systems to include consideration of plans for use of the following technologies: thin clients (for review and / or reporting); and voice over IP (for control and / or dictation).
115.8.122
Service providers shall describe how, given appropriate user authorisation, remote access functionality shall be implemented with particular reference to the use of web browser technology and ad hoc distribution, e.g. when a patient becomes unwell whilst on holiday abroad. Service providers shall give information on how issues of security regarding remote access shall be handled and whether the service is managed through dial in or dial out access.
FINAL 1.0a
Page 292 of 607
ICRS
Requirement PACS display devices 115.8.123 The specification for display devices shall follow the format stated in in the device display key for 115.8.127. Cathode-ray-tube devices shall have a minimum refresh rate of 100Hz and be noninterlaced. Non- cathode-ray-tubes shall provide an equivalent level of performance. The display devices shall be of high brightness, typically this shall be at least 500 cd/m2 for diagnostic display devices. The display devices shall have stable luminance and uniformity as defined by the service providers QA procedures. Service providers shall define the mean time between failures (MTBF) and mean time between maintenance (MTBM) along with expected lifetime in terms of hours of cumulative usage. All display devices proposed and listed below and explained in the following display device key table, shall have a facility for regular quality control and able to be calibrated to DICOM grey scale display function. Function Mammography reporting Orthopaedic reporting Cardiology reporting Radiology reporting Mammography review Orthopaedic review Cardiology review Accident & Emergency review Radiology review Ward/Clinic level review Community review Multi-disciplinary teams Teaching
Required Response
115.8.124
115.8.125
115.8.126
115.8.127
Type of Display Device E.g. A+
E.g. B1
FINAL 1.0a
Page 293 of 607
ICRS
Display device key:

Key A+ A1 A2 B1+ B2+ B1 B2 C1 C2 D1 D2 E F Minimum resolution 9 Megapixel 5 Megapixel 5 Megapixel 3 Megapixel 3 Megapixel 2 Megapixel 2 Megapixel 1 Megapixel 1 Megapixel Trust Desktop Monitor (SVGA 1024x768) Trust Desktop Monitor (SVGA 1024x768) Large Format Plasma Screen (SVGA 1024X768) Multimedia Projector (XGA -1024x768) Flat screen Projector Cathode-ray-tube
115.8.128
The range of display devices proposed shall include at least one capable of displaying images at the highest resolution possible for the purposes of mammography. The service provider shall commit to producing a report on the ergonomic and logistic aspects in all areas where images are to be displayed. In some areas space may dictate that ceilingmounted display devices are required. The service provider shall investigate the costs of ceiling mounted display devices and give consideration to the costing of colour and/or flat screen display devices. Dental Imaging: Additional Requirements
115.8.129
115.8.130 115.8.131
Dental acquisition shall act as DICOM SCU for image storage. For comparison purposes, dental acquisition shall allow display of images and reports from the PACS alongside newly acquired images. The service shall support or enhance current work practice. In particular it shall facilitate the simultaneous working of more than one clinical user with more than 1 patient.
115.8.132
FINAL 1.0a
Page 294 of 607
ICRS
115.8.133
In the event of network/interface failure, contingent arrangements for manual patient demographic data entry to the service shall be available. It shall be possible to enter the accession numbers for the examinations manually. The service shall process images acquired during failure events in exactly the same way as images acquired normally e.g. it shall be able to pre-fetch and route them. In case of network failure, the service shall have the capacity to store at least a weeks worth of patient images locally until repairs can be affected. The service provider shall also provide a means to perform and capture device sensitivity and linearity, which are capable of being conducted under normal operational conditions. During the transitional period to full PACS, all images shall be hard copied via docked or networked printers in the immediate locality, with the capacity to meet throughput. The service shall be interoperable with the wider PACS and any interfaces shall permit bidirectional data flows of patient and examination information, as well as control information such as requests for image display. The service shall support DICOM modality worklist management. The service shall have the facility for the importation of data for cephalometric analysis and orthodontic treatment planning. The service provider shall describe the facilities for error detection and reporting in the service. The service shall allow capture of orthopantograph, cephalometry, skull and facial bones and intra-oral radiographs. The service provider shall include details regarding any upgrades/ replacements of equipment necessary to allow digital capture; or details of other approaches. The service provider shall list any specific operating requirements of the services e.g. arrangements for maintaining cleanliness of intra-oral sensors with respect to potentially infectious patients. The service provider shall state the guaranteed minimum lifespan of imaging plates and or digital detectors in terms of years and
115.8.134
115.8.135
115.8.136
115.8.137
115.8.138 115.8.139
115.8.140
115.8.141
115.8.142
115.8.143
FINAL 1.0a
Page 295 of 607
ICRS
exposure cycles. 115.8.144 The service provider shall give details of any specific hard copy devices proposed for dental use. The service provider shall give details of actual and effective area of detectors for intra-oral devices. Research and Teaching 115.8.146 Users shall be able to create conference folders with shared permissions. The service shall allow users to remove all demographic headers and all annotation for the purposes of teaching, research and publishing. 115.8.147 Users with appropriate authority levels shall be able to create personal folders of images belonging to different patients. The service shall allow for the copying of images onto CD and/or DVD and to powerpoint presentations and have the facility for the stripping of headers. The service shall accommodate the ability to save images in a variety of formats, including non-proprietary, with DICOM viewing software included. The service shall accommodate multidisciplinary team (MDT) meetings where high quality image viewing facilities are required along with the facility to project images on to a screen. It shall be possible to connect some of the workstations to data projectors providing functions such as dual projector and split screen projection. The minimum standard resolution to be 1024 x 768 pixels. The service shall support the creation of groups of images/examinations associated with authorised users. (Sometimes called summary folders"). The service shall allow key images to be marked for teaching purposes and comments to be added as defined in IHE (UK) IP6. The service shall allow the construction of folders that contain images from multiple patients in the same folder. These folders shall be both accessible by one user only (personal folders) and by multiple users, where a number of named users can access and add/delete to the folder (conference folders). The service provider shall explain how the service supports authorised users in identifying images that are
115.8.145
115.8.148
115.8.149
115.8.150
115.8.151
115.8.152
115.8.153
FINAL 1.0a
Page 296 of 607
ICRS
particularly relevant for teaching or research, and in organising (e.g. in folders) and retrieving such images from the database. 115.8.154 Service providers shall explain how conferences would be managed and how the images would be scheduled, i.e. via specialty information solution (in the case of radiology, commonly referred to as a RIS) or PACS and also whether complete folder would be called or the images would only be pulled by body part specifically. PACS for Radiotherapy 115.8.155 The service shall allow for the storage and distribution of treatment planning and simulation data. The service shall also directly transmit to and from treatment equipment utilising the DICOM RT class. Radiography Images acquired during brachytherapy shall be stored on PACS. For the purposes of treatment planning, PACS shall be able to store (and archive) the dose distribution on a single slice from each treatment plan which shall be displayable together with the relevant images. The service provider shall provide information regarding DICOM RTs ability to support the export of this dose distribution. Therapy portal vision images may be stored locally on systems such as Varis, but shall need to be stored on the service too. The service provider shall suggest possible options for the input of these images to PACS. Treatment planning requires that the full datasets from CT, MRI and eventually PET images are available. These full dataset images shall be stored locally for two months and be instantly available. Thereafter the full datasets shall be archived. PACS shall include up to four fields (user configurable) per image in order to record patient dose related parameters. PACS for Cardiology 115.8.161 PACS shall support the storage and review of 3D rotational angiography, functional MRI, ultrasound and spectroscopy images. The service provider shall describe its approach to managing cardiology imaging and interfaces to separate cardiology systems, in particular cardiac archives.
115.8.156 115.8.157
115.8.158
115.8.159
115.8.160
115.8.162
FINAL 1.0a
Page 297 of 607
ICRS
115.8.163
The service provider shall be aware that the process of reporting on fluoroscopy and angiography shall require that only some of the images from an examination are selected as there may not be space in the service archive to store the entire examinations. Service providers shall explain their methodology of storing the whole examination for a period of time (e.g. 1 month) on line and then storing the snapshots from the examination in PACS archive/RAID for a longer term. Use of PACS beyond radiology
115.8.164
The PACS shall be able to access endoscopy reports such as those attached to an ERCP procedure. The PACS shall allow authorised users to manipulate endoscopic images. Investigation needs to be undertaken on whether it is possible to manipulate adequately the image when viewing through a browser. PACS shall accommodate non-radiological endoscopic, arthroscopic, and laparoscopic images. Service providers shall undertake an investigation to ensure that DICOM compliancy is in place. The service shall be capable of acquiring and storing any medical image and allowing this to be viewed throughout the service e.g. retinal screening, dermatology photographs etc. The service provider shall make suggestions as to how the accession numbering and seamless operation could be addressed. PACS Performance (additional requirements of Section 730) to the
115.8.165
115.8.166
115.8.167
FINAL 1.0a
Page 298 of 607
ICRS
115.8.168
In response to the following requirements, the service provider shall state any assumptions, particularly those concerning minimum infrastructure requirements. The service provider shall state their definition of a full load and provide details on how they calculate it. Include any assumptions on the following: Number of concurrent users. Concurrent user activities. Network Traffic. Available network bandwidth. On-line backup. Audit trail. Image sizes. Concurrent applications workstation. open on the
Concurrent applications executing on the workstation. Workstation specification. Workstation location.
115.8.169
A PACS workstation shall display the first 20 search results of any query of the service database within 2 seconds, 90% of the time, and a maximum of 10 seconds, 100% of the time. Display time is measured from the time the user completes selection of the query (e.g. th worklist selection) until the 20 result is visible on the display device.
FINAL 1.0a
Page 299 of 607
ICRS
115.8.170
The service shall display images from the following categories on all diagnostic and clinical review workstations within two seconds of request in 95% of cases and within 10 seconds in all cases whilst the service is operating under a full load: Any image which has been captured or viewed within the last 3 weeks. Any image acquired within the last five years on a patient for whom activity is scheduled for 1 days time or less (activity may be inpatient, outpatient, A&E clinic, waiting list or A&E attendance). Any image acquired within the last five years on a patient for whom unscheduled activity has occurred (activity may be inpatient, outpatient, A&E clinic, waiting list or A&E attendance) (This requirement should be fulfilled within 10 minutes of information concerning unscheduled activity being received by the PACS). Any images that are stored off-line shall be retrievable within 10 minutes; any images stored on near-line storage shall be retrievable within two minutes.
115.8.171
The service shall display images from the following categories on all diagnostic and clinical review workstations within 30 seconds of request in 95% of cases and 100% within 120 seconds whilst the service is operating under full load: Any image not in the categories listed in N 02 above.
115.8.172
The service shall indicate that it is working during any operation that does not have instantaneous results. Retrievals to be performed in the background and not to impact on the use of the workstation for any other activities. The user to be alerted when requested images have been fetched from archive. The service shall support all functions in achieving retrieval concurrently without detriment to the overall performance. The service provider shall state any assumptions that have been made. The service provider shall demonstrate the scalability of their solution along with flexibility to deal with the following occurrences: The handling of peak workloads of twice
115.8.173
115.8.174 115.8.175
115.8.176
FINAL 1.0a
Page 300 of 607
ICRS
the average daily throughput in one day. To repeat any batch backups during the day without interruption to the normal operation of the service. In the instance of an emergency data overload (e.g. data from another site). a sustained increase in data load due to an increase in patient activity.
115.8.177
Where CR is supplied, the service provider shall state how many images a multi plate CR reader shall be capable of capturing and storing per hour by image size : SIZE 18 X 24 24 X 30 18 X 43 30 X 40 35 X 35 35 X 43 Others Capture/h Store/h
115.8.178
In the context of CR the service provider shall complete the table with response times in seconds for each function. The service provider shall state any assumptions made. For image retrieval it is required that 95% of images are viewed within no more than 2 seconds and analysis of those images not displayed within this timeframe shall be required from the service. Function User log on Search for image Retrieve image Annotate Image Update/edit Image Ad query Hoc Achieved in 95% of cases Achieved in 100% of cases
115.8.179
Where DR is supplied, the service provider shall state how many images a DR system shall be capable of capturing and storing per hour by image size. SIZE Capture/h Store/h
FINAL 1.0a
Page 301 of 607
ICRS
18 X 24 24 X 30 18 X 43 30 X 40 35 X 35 35 X 43 Others 115.8.180 In the context of DR the service provider shall complete the table with response times in seconds for each function. The service provider shall state any assumptions made. For image retrieval it is required that 95% of image are viewed within no more than 2 seconds and analysis of those images not displayed within this timeframe shall be required from the service. Function User log on Search for image Retrieve image Annotate Image Update/edit Image Ad query 115.8.181 Hoc Achieved in 95% of cases Achieved in 100% of cases
The service provider shall describe how the proposed solution can be upgraded to meet increases in numbers of workstations and numbers of images without adverse affects on performance. The service provider shall describe the functionality provided within the service to monitor and measure its performance. The service provider shall give details, including calculations where appropriate and any assumptions made, to support claims that the proposed solution shall meet performance targets. The retrieval and display times for different types of images under different levels of solution loading shall be tabulated. The service provider shall provide detailed sizing algorithms in order to achieve the
115.8.182
115.8.183
115.8.184
FINAL 1.0a
Page 302 of 607
ICRS
required performance assumptions made. 115.8.185
and
state
all
The service provider shall provide examples of other sites performance sizing information and the configuration implemented to confirm the accuracy of their performance calculations. PACS Availability
115.8.186
It is required that the service is available continuously 24 hours per day, seven days per week. Periods of unavailability shall be measured from The formula to be used is: the time the incident is reported until the time the ((time periodlength of unplanned service or particular item of equipment is downtime)/time period) x 100. restored to full operation. During the operational time 24 hours per day seven days per week, including public holidays (i.e. 168 hours), the minimum operational solution shall have an availability of at least 99.9% when measured monthly but reviewed quarterly. The maximum continuous period that the minimum operational solution is unavailable shall not exceed one hour. The number of incidents which cause the minimum operational solution to be unavailable during the operational time over a 28-day period shall not exceed five. The elements comprising the minimum operational solution shall differ between the Authorities, but as a minimum shall include the image archive, the interfaces to the specialty information solution (in the case of radiology, commonly referred to as a RIS) and PAS/HIS, interfaces to some modalities, the web server, if any, and a specified number of workstations and hard copy devices. The exact details shall be determined in discussions with individual Authorities. No one item of equipment in the whole solution during this operational time shall have an availability of less than 95% when averaged over a 28 day period. The service provider shall state that they can meet this requirement. The service provider shall state the expected The formula to be used is: average % planned downtime over 1 week, 1 (1-(time periodlength of month, 6 months and 12 months using the downtime)/time period) x 100. required formula. Continuity of power supply for some specified components of the service is essential. The service provider shall specify those components that shall be supplied with UPSs. PACS Integration with other systems (in addition to general requirements in Sections 770, 780 & 790) planned
115.8.187
115.8.188
115.8.189
FINAL 1.0a
Page 303 of 607
ICRS
115.8.190
The PACS service shall be fully integrated with The service provider shall propose a other systems within the Authority. method for mapping all site-based identifiers currently used across the systems within an Authority to enable integrated running of a community PACs. The service shall have an indexing system such that the patient has a single folder for the whole solution (multiple Authorities) regardless of where the image was taken. The service provider shall supply an indexing system that shall allow all patients images to be uniquely identified irrespective of point of capture in the service. This folder/image shall be accessed by searching on any of the individual Authoritys specialty information solution (n the i case of radiology, commonly referred to as a RIS/PAS (ICRS when available)) identifiers at any site. The service shall in time be required to integrate with the national transaction and messaging spine and service providers shall describe their approach to this integration.
115.8.191
115.8.192
As a minimum, the database shall be capable of storing the following patient information associated with each image/examination: family name, first name, previous name(s) where applicable, hospital number(s), NHS number, date of birth, specialty information solution (in the case of radiology, commonly referred to as a RIS) examination number, accession number, date and time of examination, modality, body part, referring clinician, supervising specialist clinical user s patient status (e.g. GP, inpatient, outpatient etc.). It shall be possible to select and display images by patient name, hospital or specialty information solution (in the case of radiology, commonly referred to as a RIS) number, NHS number, date of examination, modality, body part, relation to another examination, requesting clinician, supervising specialist clinical user , exam location, patient status (e.g. GP, inpatient, outpatient etc.) or combinations of these. The workstation shall provide a quick and easy way to select the presentation, which shall be clear and intuitive.
115.8.193
FINAL 1.0a
Page 304 of 607
ICRS
115.8.194
The database shall be integrated to the specialty information solution (in the case of radiology, commonly referred to as a RIS/PAS (ICRS when available)) at each site so that the service is able to accept and process information relating to clinic times, dates, patient attendance and ward changes such that pre-fetch and data management algorithms can be used where necessary. The database shall be capable of functioning independently of Authorities specialty information solution (in the case of radiology, commonly referred to as a RIS) and PAS (ICRS when available) systems in case of either or both systems being unavailable. This shall include the acceptance and viewing of patient demographic data and examination details including those not already known to the service. The service shall be capable, with minimum operator intervention, of aligning the databases after such a period of independent operation. Mechanisms for correction of data integrity errors, alignment of Authorities PACS with their specialty information solution (in the case of radiology, commonly referred to as a RIS) databases and similar problems are required. Emphasis shall be placed on the ease of use of this corrective functionality. The interfaces to an Authoritys specialty information solution (in the case of radiology, commonly referred to as a RIS) shall allow passage of referral/request information f om the r specialty information solution (in the case of radiology, commonly referred to as a RIS) to the PACS such that authorised users have access to it via PACS workstations and CR units. For each examination, users shall be able to determine patient demographics, referring clinician, type of examination, reasons for the examination and date of request. It is required that service providers give a breakdown of the demographic details of which the service is capable of storing. The service shall provide a unified view of all examinations across all connected hospital domains. This shall not be interpreted as requiring a specific architecture. Rather it requires that the user be able to find and access any examination known to the service without knowing details of the architecture. This requirement shall not be interpreted as precluding location-specific default views of the database.
115.8.195
115.8.196
115.8.197
115.8.198
FINAL 1.0a
Page 305 of 607
ICRS
115.8.199
The service will be extended to other nonradiological forms of imaging in future. The design of the service shall allow for such developments during the expected life of the service, which shall be stated by the service provider. The service provider shall state by workstation type which third party software can be used without degradation to the performance criteria, e.g. windows office and Authority virus software. The service provider is responsible for ensuring that all contracted imaging-related elements supplied shall be interoperable and integrated into the overall solution as part of the implementation process.
115.8.200
115.8.201
FINAL 1.0a
Page 306 of 607
ICRS
115.8.202
The workstations provided for desktop integration shall, according to user preference, be provided in one of the following configurations: 2 display devices for viewing images and 1 colour display device for specialty information solution (in the case of radiology, commonly referred to as a RIS). 1 display device for viewing images and 1 colour display device for specialty information solution (in the case of radiology, commonly referred to as a RIS). 2 display devices for viewing images with the option of interacting with specialty information solution (in the case of radiology, commonly referred to as a RIS) on 1 of these display devices. Workstation display devices shall be controlled by a single keyboard and mouse. The PACS and specialty information solution (in the case of radiology, commonly referred to as a RIS) application shall be linked in such a way that examination information selected on the specialty information solution (in the case of radiology, commonly referred to as a RIS) display device shall cause relevant images to be shown on the PACS display devices according to the relevant default display protocols (DDPs) and selection of images/examinations on the PACS display devices shall cause the relevant specialty information solution (in the case of radiology, commonly referred to as a RIS) examination data to be displayed on the specialty information solution (in the case of radiology, commonly referred to as a RIS) display device. There shall be a single log on to the services such that a user logging on to the PACS shall also be logged on to the specialty information solution (in the case of radiology, commonly referred to as a RIS) and vice versa, where it is appropriate for a user to be logged on to both systems. All functions permitted to the user of the specialty information solution (in the case of radiology, commonly referred to as a RIS) and PACS shall be available (including digital dictation where installed) through the single workstation with desktop integration.
FINAL 1.0a
Page 307 of 607
ICRS
115.8.203
The PACS shall incorporate interfacing of three dimensional image data into other systems that require this, e.g. radiotherapy systems, stereotactic biopsy systems, robotic surgery systems and image assisted surgery systems. The service provider shall act as prime contractor for the supply installation upgrades and maintenance of all interfaces relating to this project. The interface shall be able to operate both in Bidders must indicate which interface real time, or pseudo real time, and batch mode. modes are supported. The database shall be ODBC compatible and support SQL. The service provider shall state clearly which database is used. The service provider shall provide for interfaces to all existing modalities at each site. The service provider shall be provided with a locally generated list of modalities in use in the locality and shall undertake a review of these modalities as part of its diligence report. The service providers shall provide a table of all existing modalities and show how these can be connected to the PACS solution and the related cost. The Authority shall then decide which of these options to take up. The service provider shall state their policy, plans and timescales for migrating communications to HL7 v3 messages. The service provider shall state how its solution re-aligns and re-indexes the database records after the specialty information solution (in the case of radiology, commonly referred to as a RIS) and/or PAS (ICRS when available) system or the interface to any such system - has been down and the PACS has been operating independently.
115.8.204
115.8.205 115.8.206
115.8.207
115.8.208
115.8.209
FINAL 1.0a
Page 308 of 607
ICRS
115.8.210
This document recognises the importance of automating as far as possible all communication between PACS, other computer systems and modalities. Thus, in addition to DICOM functionality required to produce a solution which shall function at a basic level (query retrieve, store, print etc), it is expected that the widest ranging and earliest implementation of features such as DICOM Performed Procedure Step and Storage Commit functionality shall be provided. Details shall be supplied of precisely which DICOM features it is proposed to implement in the interface to each of the modalities and systems with which it shall communicate. (It is recognised that in many cases the modality, rather than PACS shall determine this.) The service provider shall maintain the service in line with DICOM developments, in that all relevant DICOM attributes are made available in a timely fashion.
115.8.211
The service provider shall supply with the proposal and without charge, one or more DICOM conformance statements covering all DICOM functions of the proposed solution. On request the service provider shall provide conformance-testing results that validate DICOM conformance statements without charge. The service provider shall indicate how PACS shall interface with remote electronic ordering (order- comms) functionality via specialty information solution (in the case of radiology, commonly referred to as a RIS). PACS -related network requirements (in addition to Section 730)
115.8.212
115.8.213
115.8.214
Although proprietary protocols may be used within the service for internal communication, the service shall be able to support TCP/IP and FTP protocols over ethernet for communicating with other devices outside the PACS. Facilities shall be provided whereby authorised users can monitor the performance of the network and change configurations, alter priorities or stop tasks as appropriate in order to maximise performance and address problems. A level of redundancy shall be built into the network to protect against failure. The service provider is required to suggest the various methods by which this may be achieved and the levels of protection conferred, although this shall be provided through another project or
115.8.215
115.8.216
FINAL 1.0a
Page 309 of 607
ICRS
the Authority themselves. 115.8.217 Service providers shall be required to review the Authority's current network to ensure that it shall deliver the PACS performance requirements stipulated above without compromising the performance of any system currently using the network and the availability requirements stated above. Where the current network is not capable of delivering the performance and availability standards required, the service provider shall make proposals to implement any upgrades required. For all commercial off the shelf operating software (e.g. Windows, network OS, Unix, Oracle) used in providing the service, the service provider shall maintain in a timely fashion the software patches, bug fixes and new service pack updates. PACS Security (in addition to general requirements given in Sections 710, 720 & 730) 115.8.219 The service shall protect against the loss of The Bidder shall describe images and data in particular indexes linking solution achieves this. reports to images. The service provider shall describe how the service ensures that images are not altered during transmission or accessed by unauthorised connection to the service and describe how this is reported. The service shall be fault tolerant and state the The Bidder shall describe up time guaranteed and the definition of such. mechanisms to achieve this. Furthermore, automatic logging of tolerated faults is required. Any procedures to ensure data integrity and The Bidder shall describe security, including backup, shall be able to be mechanisms to achieve this. carried out with no effect on the normal operation of the servi ce. If these procedures need to be done out of peak usage hours, the requirement for such procedures, which shall not without operator intervention, shall be declared. The service shall provide the ability to copy security templates between users. The service shall provide the ability for the system administrator to assign access levels and privileges (including view only, edit, etc.) by certain criteria, e.g. individual, group, template. The service shall provide a mechanism for an automatic timeout based on user log-in ID and password i.e. after an interval of inactivity defined by the system administrator, the service shall mandate another password entry. Images shall be released and workstations remain free the how its
115.8.218
115.8.220
115.8.221
115.8.222
the
115.8.223 115.8.224
115.8.225
FINAL 1.0a
Page 310 of 607
ICRS
for use by other users.
115.8.226
It is essential that effective anti-virus measures, including the implementation of regularly updated detection and recovery software, be implemented and managed at points where any malicious code may enter a system or network. This shall have no detrimental affect to solution performance. Service providers shall ensure that reasonable systems are in place to ensure compliance with the Information Management and Technology Controls Assurance Standard (NHS Executive IM&T Controls Assurance Standard 10). The database shall provide an access control mechanism that enables assignment of unique privileges to individual users and user-groups to access or alter solution resources and data e.g. display images, print images, ad hoc database queries (worklists etc.), send images via teleradiology system. This assignment/alteration/suspension of privileges shall be under the sole control of the system administrator and authorised users.
115.8.227
115.8.228
A solution-wide administration function shall be provided to facilitate user and group profile, worklist query creation, solution configuration management, data integrity checks, maintenance and any other administrative functions as required by the implementation of the product. A graphical user interface shall be provided for this function. All data that is stored shall be done in true DICOM 'store 10' format, particularly for removable media. Where private tags are added, these shall be clearly identified and the ability to switch them off shall also be provided, particularly for data migration techniques. In addition service providers shall present a solution for monitoring and correcting duplicate entries and errors for both the new archive and any existing legacy archives connected to the PACS. Ideally this shall be part of the quality assurance process. This shall be demonstrated in a clinical environment in the UK, not a demo suite. The service provider shall describe how the service limits access to patient related information, by reference to certain criteria, for example: user ID and password (or smart card), patient class e.g. gu medicine, patient location,
115.8.229
115.8.230
FINAL 1.0a
Page 311 of 607
ICRS
application/menu/function, data element, time, workstation location. 115.8.231 115.8.232 The service provider shall describe the system to protect password integrity. A description shall be given of tools provided for troubleshooting faults. Details of provision for network and resource monitoring are also requested. PACS audit and clinical governance (in addition to general requirements given in Section 730) 115.8.233 All plates and cassettes shall be clearly individually identifiable, both externally on the cassette and on the image. This is essential for the purposes of error tracking and quality control. Service providers shall explain how this shall be achieved. An indication of radiation exposure to the patient shall be stored, and ideally displayed, with the image. The service shall provide a mechanism to support quality review of CR images and permit the operator to take remedial action. Remedial actions include image flip (top to bottom, left to right) image rotation, window width and level, correction of side markers and image processing. The identity of the operator making any changes, the date and the time shall be recorded and be available with the images. Where the image display characteristics that have been changed by the operator at the CR unit, it shall be possible to save the display characteristics such that they become the default display settings for future display of the image. Service providers shall describe how radiation exposures factors are recorded in order to permit local compliance to Ionising Radiation Medical Exposure Regulations 2000 (IRMER). Image quality control functionality shall include computation of mean and standard deviation of pixel values in user defined areas.
115.8.234
115.8.235
115.8.236
115.8.237
FINAL 1.0a
Page 312 of 607
ICRS
115.8.238
The service provider shall be aware of the current legal requirement around the length of time breastwork images need to be stored and ensure that PACS accommodates this need. Authority policy on the retention of films is in line with Guidance contained in HSC 1999/053 For the Record. Oncology images shall be kept for 8 years after conclusion of treatment. Clinical-trial images shall be kept for 15 years after conclusion of treatment. Paediatric and maternity images shall be kept for 25 years.
115.8.239
The service shall, through integration with other systems such as specialty information solution (in the case of radiology, commonly referred to as a RIS), support the searches necessary for audit, peer review, research and teaching. The service shall provide comprehensive audit reports that include the following items: user ID, date and time, workstation and transaction. The service provider shall provide details of mechanisms whereby exam data can be associated with specific CR plates. The service provider shall state what objective measures of image quality control are available. The service provider shall state the dynamic range for each combination of DR detector/pixel size. The service provider shall provide a plot of MTF (modulation transfer function) against spatial frequency for each combination of DR detector/pixel size. The service provider shall provide graphs of DQE (detective quantum efficiency) against spatial frequency for all detectors within dental imaging. The service provider shall state the dynamic range of the service within dental imaging. The service provider shall supply a plot of MTF (modulation transfer function) against spatial frequency for all detectors within dental imaging. The service provider shall give data that provides comparison of the patient dose for the digital image receptors they propose and for conventional analogue receptors (screen/film
115.8.240
115.8.241
115.8.242
115.8.243
115.8.244
115.8.245
115.8.246 115.8.247
115.8.248
FINAL 1.0a
Page 313 of 607
ICRS
systems). The conditions used for each (please detail) shall be representative of best practice and the doses shall be for patients of the same size, which shall be indicated. PACS User Training (in addition to those prescribed in Section 940) 115.8.249 All relevant staff groups shall be appropriately trained at the outset and the training shall be reviewed after six months by the Authority, by the service provider, and by the Authority and service provider jointly. The service provider shall supply experienced PACS trainers to train Authority staff. The service provider shall provide details of the training team to support the implementation, to include: previous PACS training experience, previous involvement in PACS solution implementation and detailed experience of the proposed solution. Supplier shall provide a training schedule. Training shall be both structured and timely. It shall produce a workforce that is competent in all required aspects of the operation of the PACS and its peripherals. Service providers shall present their strategy and innovative solutions to meet the training needs of a large scale PACS solution rollout across their LSP area, taking into account modality and sitespecific issues. The maintenance of a small core team of Authority staff members who can act as skilled trainers shall be vital to the success of this project. Additional Authority staff shall be seconded, generally on a part-time basis, for the period of the implementation. These groups shall be trained by the service provider. Training shall highlight the need for local contingency plans for use when functions of the service do not work. All documentation shall be provided both on-line (and/or electronically) and in hard copy form (see INS 02 below). Service providers shall confirm that printing on-line documentation and duplicating hard copy documentation for use within the Authority shall not breach their copyright. The service provider shall supply details of their approach to computer based training packages and on-line training support. The service provider shall supply details of
115.8.250
115.8.251
115.8.252
115.8.253
115.8.254
115.8.255
115.8.256
115.8.257
FINAL 1.0a
Page 314 of 607
ICRS
training support provided post-implementation. 115.8.258 115.8.259 The service provider shall outline the proposed training strategy. The service provider shall state any prior training or qualifications required before any member of staff is considered suitable to participate in the service providers training programme. Training methods and philosophies shall be clearly stated. The service provider shall detail the training required to meet the specific needs of particular users, including: PACS administration specialist(s), needing a detailed understanding of the PACS implementation in order to administer the archive, users etc. PACS IM&T specialist(s), needing a detailed technical understanding of the PACS implementation in order to manage the technical environment and its link to the rest of the hospital IM&T infrastructure, and provide first line support. Medical Physicist necessary for the support of CR, DR, display devices. Specialist clinical users, needing to use high level, specialist workstations for diagnosis and reporting. Clinical users, needing to use computerised radiology equipment and workstations to check, validate and notate images. Specialist clinical users, needing to use specialist workstations for diagnosis and viewing. Other clinical users, needing to use PC web browsers for viewing.
115.8.260 115.8.261
Some clerical users needing to use the service in support of clinicians, etc. Details shall include time required and content of each module and maximum group size. 115.8.262 The service provider shall describe or preferably supply examples of the following: trainer documentation, trainee documentation, lesson plans, structured course programme, evaluation forms that form part of the training program. This shall also include training packages for new radiology and clinical staff. PACS installation 115.8.263 The service provider shall make arrangements for a hand over period of at least 6 months,
FINAL 1.0a
Page 315 of 607
ICRS
during which time PACS shall be capable of printing images onto hard copy allowing both current and filmless systems to run concurrently. 115.8.264 Under the conditions of this procurement the service provider shall deliver the following implementation services: Integration of all new hardware and software with existing, retained, hardware and software into a fully functioning solution which meets the requirements stated in this specification. Integration of imaging equipment including fixing of DICOM protocols. Setup of code tables to national and Authority standards as appropriate.
Setup of interface software to map PACS code tables to code tables of external systems. The service provider shall state for each service how it shall be provided. 115.8.265 The individual Authorities shall be responsible for the provision of the physical environment required to support the service. However, the service provider shall give full details of the physical environment requirements, including space, minimum access clearances during installation (i.e. minimum door frame sizes, etc.), load bearing capacity, electrical supply, water, drainage and cooling requirements for each item of equipment proposed. PACS maintenance and support (in addition to those prescribed in Sections 600, 760, 985) 115.8.266 The service provider shall provide continuing support and training for the service for the duration of the contract. The service provider shall have a centrally based support team and shall provide recommendations for support based on PACS OBS parameters. The Authorities shall provide PACS solution managers locally. The service provider shall accommodate, free of charge, any change to the required PACS that is brought about by changes in legislation. The service provider shall provide solution critical upgrades as part of the maintenance and support agreements.
115.8.267
115.8.268
115.8.269
FINAL 1.0a
Page 316 of 607
ICRS
115.8.270
The service provider shall upgrade hardware in the event that a software upgrade adversely affects solution response or availability. Service providers shall declare their policy with respect to the cost to Authorities of meeting this requirement. The service provider shall indicate the expected life span of the service and its components.
115.8.271
115.9 115.9.1
Mini-Cluster Model Purpose This section is designed to provide realistic information on a typical mini-cluster which can be used to produce a model against which initial LSP offers can be benchmarked prior to final contract negotiations. The 4 model Trusts below are based upon actual NHS Trusts and represent the variety on infrastructure and technological capability available in the NHS. Trust A represents a Trust with an advanced network infrastructure and IT support with a high proportion of DICOM enabled modalities, down to Trust D which has a poor network infrastructure and IT support with very few DICOM enabled modalities. Suppliers are requested to cost and specify an indicative solution based on this data and their response to section 115 of the ICRS OBS2. In addition a full schematic of the proposed solution must be provided. Background
115.9.2
Workload/Workflow General details of work load and workflow for each of the Trusts within the mini-cluster model are provided below:
Trust A: Conducts approximately 365,000 imaging examinations per year
FINAL 1.0a
Page 317 of 607
ICRS
General Radiography
Fluoroscopy
CT (inc. RT Planning)
Ultrasound
Nuclear Medicine
Site 1A Main Site 1A Cardio Site 1A Site 2A Main Site 2A Neuro Site 3A Main X-ray 1
45974
2258
15220
9367
4023
2085
14309
2713
15983
1926
26
3999
370
2021 54145
1 749
21 2536 1715 3
1 2
4 5559 1371
5827 19177
79 205
144 3301
5750 413
5865 4076
966 6
1101 1790
490 247
Site 3A Main X-ray 2 Site 3A US Site 3A BS Site 3A Dental Site 4A Cancer Site 4A Main
24253
1610
9190
6572
79
6385
438
11000 404 2121 28440
13445 16 5535
11513
4701
Unspecified
808
61
247
122
167
15
222
73
Totals
186738
6889
43822
29474
14135
7153
29740
5337
28440
11513
Trust A: Non-Radiological Images: Medical Physics
FINAL 1.0a
Page 318 of 607
Other (specify)
Mammo
Mobiles
Theatre
Dental
Angio
Department and Site
Cardiology
MRI
ICRS
Department Site 1A Site 2A Site 3A
Number of Exams 3000 4500 3500
Trust A: Modality Data Sizes

Modality Average Number of Images per Exam 2 15 15 200 200 20 1 2 4 4 4 8 Average Data/Matrix size per Image (Mb) 8 0.4 0.25 0.4 0.4 1.25 8 8 10 0.2 8 0.02 Average Data/Matrix size per Exam (Mb) 16 5.6 3.75 80 80 25 8 16 40 0.8 32 1
General Radiography Fluoroscopy Ultrasound CT MR Angiography Mobiles Theatre Mammography Dental Cardiology Medical Physics
Trust B: Conducts approximately 152,000 imaging examinations per year

Other (specify)
General Radiography
Fluoroscopy
Nuclear Medicine
Mammo
Mobiles
Theatre
Angio
Site 1B main Site 1B DTC
74875
1392
25200
5593
2336
825
3250
5940
649
21000
5000 79875
2000 3392
100 25300
500 6093
1000 3336
50 875
50 3300
0 5940
2000 2649
0 21000
FINAL 1.0a
Page 319 of 607
Dental
Department and Site
Cardiology
Ultrasound
MRI
ICRS
Totals
Trust B: Non- Radiological Images

Department Site 1B Echocardiography Site 1B Coronary Angiography Site 1B Endoscopy/Colposcopy Site 1B - ERCP Number of Exams 4000 800 7000 120
Trust B: Modality Data Sizes:

Modality Average Number of Images per Exam 2 15 15 400 200 250 1 2 2 1 80 Average Data/Matrix size per Image (Mb) 8 0.4 0.25 0.4 0.4 1.25 8 8 10 0.2 1.25 Average Data/Matrix size per Exam (Mb) 16 5.6 3.75 160 80 313 8 16 20 0.2 100
General Radiography Fluoroscopy Ultrasound CT MR Angiography Mobiles Theatre Mammography Dental Cardiology
Trust C: Conducts approximately 172,000 imaging examinations per year

Other (specify)
General Radiography
Fluoroscopy
Nuclear Medicine
Mammo
Mobiles
Theatre
Angio
FINAL 1.0a
Page 320 of 607
Dental
Department and Site
Cardiology
Ultrasound
MRI
ICRS
Site 1C main Site 1C Community
122492
29783
8306
3592
51
2553
248
Totals
122492
30031
8306
3592
51
2553
Trust C: Non- Radiological Images
None included.
Trust C: Modality Data Sizes

Modality Average Number of Images per Exam 2.1 18 9.5 90 60 15 1.4 3 6 4 Average Data/Matrix size per Image (Mb) 8 0.4 0.25 0.4 0.4 1.25 8 8 10 0.2 Average Data/Matrix size per Exam (Mb) 17 7.2 3 91 24 19 12 24 60 1
General Radiography Fluoroscopy Ultrasound CT MR Angiography Mobiles Theatre Mammography Dental
Trust D: Conducts approximately 235,000 imaging examinations per year
FINAL 1.0a
Page 321 of 607
ICRS
General Radiography
Fluoroscopy
Ultrasound
Site 1D Site 2D Site 3D Site 4D Site 5D Site 6D Site 7D Site 8D
28033 67054 55313 7080 2449 1933 5723 7552
942 1823 762
10709 8769 11734 2678 11
864 2731 4237
500 1500 1432
109 946 1208
1343 2515 2295 351
202 3729
557 867 263
Totals
175137
3729
35325
7832
3432
2263
Trust D: Non- Radiological Images
None included.
Trust D: Modality Data Sizes

Modality Average Number of Images per Exam 2 20 10 150 150 Average Data/Matrix size per Image (Mb) 8 1 0.5 1 0.5 Average Data/Matrix size per Exam (Mb) 16 20 5 150 75
General Radiography Fluoroscopy Ultrasound CT MR
FINAL 1.0a
Page 322 of 607
(US OBS)
Nuclear Medicine
Mammo
Mobiles
Theatre
Department and Site
Cardiology
Angio
Dental
Other
MRI
ICRS
Mammography Dental
4 1
10 8
40 8
115.9.3
Information systems
Trust A B C D
Supplier HBOC TOREX unknown HSS
Product Name McKesson RIS RMSW unknown CRIS3 (java version)
Version Version 8 Version 7 unknown SCO open server release 5
115.9.4
Central IT Provision
FINAL 1.0a
Page 323 of 607
ICRS
Trust A:
Network. Switched ATM network. TCP/IP protocol. 100 MBPS to the desktop. All CISCO switched, no hubs. Fibre optic back bone (Gb) with triangulation on site and between all five sites. The network is the largest private switched network in the North of England, over 5000 devices, 3,500 e mail accounts, 1.8 million pathology results per year, the network processes I million e-mail transactions per week. NHSnet link currently being upgraded to 2 Mbps. FM Support. The current RIS and PAS are under a facilities managed arrangement through HBOC Mc Kesson. However both are to be replaced. There is NO FM arrangements for corporate IT support. Clinical Systems. ALL clinical systems have maintenance agreements with system suppliers. All other support and development is completed through the IT department. Staffing Levels. The staffing levels are increasing at the time of publication. The IM&T department is split into three sections; IT, IS and EPR procurement. The following table shows the breakdown of the IT function. IT Manager Deputy It Manager Infra structure Development & Integration ETD Project Management Security 1.5 wte 3 wte 1 wte 1 wte 1 wte 14 wte 6.5 wte
The section currently offers Monday to Friday 8 am to 6 pm support, with on call over the weekend. Work will be undertaken over the weekend upon request.
FINAL 1.0a
Page 324 of 607
ICRS
Trust B: Trust network is based on Gigabit Ethernet core Cisco Catalyst 6509 central switch with 256Gb backplane, with all key servers directly connected to 6509 via gigabit fibre links. All local edge switches are Cisco Catalyst 2950/3900 series, with switched full-duplex 100Mbps links to desktops, and full-duplex gigabit fibre link to core 6509 Catalyst switch. All scanners (CT, MR, etc) and radiology workstations are linked to the network over fullduplex 100Mbps connections. IT staffing levels are 7 desktop support, 3 LAN/WAN support, 3 applications support and 1 IT Security. Working hours are 8am 5:30pm, with team of 4 providing out-of-hours cover. NHSNet connection is currently 2Mbps provided by BT Health, shortly to be upgraded to 34Mbps, still with BT Health. WAN links are in the process of being upgraded from ISDN or 2Mbps Telewest leased lines to minimum 10Mbps LES or wireless links, and key inter-site links will be 100Mbps. Current network loads are less than 2% on any of the key links. Trust C: Topology CHS network is a star topology radiating outwards from the Core switch. Fibre connections run to the edge cabinets, which are connected, via transceivers to switches or hubs or terminating in direct fibre connections in these edge devises. Approximately 70% of these connections run at 100mb - 30% at 10mb Edge Equipment The vast majority of equipment housed in the cabinets are 10/100mb switches (primarily 3com 3300 or 4400 models) however, there are still a number of 100mb hub in some areas. The primary medical system within the Trust (HISS) also requires the use of termservers and there are at least one per cabinet, possibly up to 5. Core Devices The core equipment is a Cisco 6509 chassis with duel power supply and one supervisor card. Connectivity includes: 1* MTRJ 100FX x 48 port blade (48 ports
FINAL 1.0a
Page 325 of 607
ICRS
utilised) 1* RJ45 10/100 48 port blade (48 ports utilised) 1* RJ45 10/100 48 port blade(48 ports utilised) Network Loading Recent network loading has shown an average CPU utilisation on the core switch of 5-10% maximum load seen 22%. Network Services Staff/IT Helpdesk The helpdesk operates Mon-Fri from 0800 17.00 and is staffed by 1 telephone operator and 3 full time helpdesk staff and 1 helpdesk supervisor. Trust D: No specific details available. Attached in section 6 - network diagrams 115.9.5 Equipment List
Trust A:
Manufacturer Modality and/or Workstation Model Date of installation Software Version DICOM Service Classes
Siemens
MRI
1 Tesla Magnetom
Aug 1994
VA33D
SEND,Q/R, HIS/RIS, PRINT
Siemens
CT
Somatom Vol Zoom
March 2001
VA40C
Siemens
CT
Virtuoso
2001
VA31C
SEND,Q/R, PRINT
Siemens
Server
Magic Web
2001
VA22A
SEND, Q/R Purchasable options are send, print HIS/RIS in development and will be an option.
Siemens
Ultrasound
Sonoline Elegra
Aug 2001
6.0.300 *may have just been upgraded
FINAL 1.0a
Page 326 of 607
ICRS
Siemens
Fluoro Room 2
Sireskop 5/45 & Digital
Nov 1996
None
Siemens
Fluoro Room 3
Polystar
Nov 1993
None
Siemens
Angio room
Angio star
Feb 1990
None
Siemens
Angio theatre
Image intensifier
Second had purchased 1997
N/A
N/A
Siemens
Theatre orthopaedic
Siremobile compact
Feb 1999
N/A
N/A
Siemens
Urology theatre
Siremobile compact
April 1998
N/A
N/A
Siemens
Urodynamics
Uroskop
Jan 1991
N/A
N/A
Sonosite Ltd
Portable ultrasound scanner
Sonosite 180
Jan 2002
None
Toshiba
Ultrasound scanner
Sonolayer SSH-140A
None
Agilulent
Ultrasound
Image Point
March 1997
N/A
None.
Siemens
CT reporting
Leonardo
March 2002
Syngo 2002a
Send, Q/R, Print
Siemens
General x-ray room
Multix Top
March 2001
N/A
N/A
Siemens
Cath 1
Artis Biplane
Dec 2001
Vb20e
SEND, Q/R, HIS/RIS, PRINT
FINAL 1.0a
Page 327 of 607
ICRS
Siemens
Cath 2
Hi-Cor
Oct 1986
GATEWAY PC REQ.
Siemens
Cath 3
Coroscop
Nov 1994
GATEWAY PC REQ.
Siemens
Cath 4
Artis
Sept 2001
Siemens
Cardio Reporting
Leonardo
March 2002
Syngo 2002a
SEND, Q/R, PRINT
Siemens
CT
Volume Zoom
2002
VA40B
Toshiba
Fluoroscopy
Eps-30
1995
None
Siemens
U/Sound
Elegra
2001
6.0.300 *may have just been upgraded
Purchasable options are send, print, HIS/RIS in development and will be an option.
Siemens
CT
Leonardo
2002
Syngo 2002a
NGH
U/Sound
Sonolayer 140
1996
6.82
None
Philips
Interventional
V3000
1999
R6
Print & Store
Philips
MR
Intera 1.5T
2001
R8
Print Store & RIS
Philips
MR
Easyvision
2001
R4
Print Store Query & retrieve
Philips
Angio
Easyvision (R2)
2001
R4
Print Store
FINAL 1.0a
Page 328 of 607
ICRS
Query & retrieve
IGE
CT
CTi
1998
4.4
Print Store Query & retrieve Worklist available Cost 4.950
IGE
CT
Advantage Windows
1998
3.1
SDC, DICOM Worklist available
Philips
Mobile II
BV300
1999
R1
Print
Philips
Inter Ventional
Multi Diagnost 2
1992
R3
None
Philips
Fluoro
Easy Diagnost
2001
R5
Print, Store & RIS
Philips
Fluoroscopy
Easyvision
2001
R4
Print, Store, Query & retrieve
Philips
MR
Easyvision
2001
R4
Print, Store, Query & Retrieve
Philips
Server
Easyweb
2001
R2
Store, Query & Retrieve
Philips
MRI
Gyroscan Intera 1.5T
2001
R8
Print, Store & RIS
Siemens x 2
U/Sound
Elegra
2001
Purchasable options are send, print, HIS/RIS in development and will be an option
FINAL 1.0a
Page 329 of 607
ICRS
Keymed
Endoscopic Ultrasound
EU - M30
1996
None
Toshiba
U/Sound
Power vision 7000
1997
3.01
None
Toshiba
U/Sound
Power vision 6000
1999
2.6
None
Toshiba
U/Sound
Eccocee
1999
4.31
None
Toshiba
U/Sound
Eccocee
1997
4.21
None
Toshiba (Loan research)
U/Sound (Endoscopic)
Power Vision 6000
2001
4.01
None
Siemens
CT
Somatom Volume Zoom Virtuoso
2001
VA40C
SEND, Q/R, HIS/RIS, PRINT SEND, Q/R, PRINT Print
Siemens
CT
2001
VA31C
Acuson
Paeds (SCBU)
Aspen
1999
Siemens
CT
Leonardo
2001
Syngo 2002a
SEND, Q/R, PRINT
Siemens
Mammo
Nova 3000
Oct 2000
N/A
N/A
Siemens
Mammo
Nova 3000
Feb 2001
N/A
N/A
Siemens
U/sound
Sienna
July 2000
GATEWAY PC REQUIRED. Esoft (use sof tware below) Link (see DICOM send/retreive None
Siemens GE
NM NM
e-cam Camstar
2001 1994
FINAL 1.0a
Page 330 of 607
ICRS
Link Medical
NM
1998
MAPS 10000
DICOM send/retreive
Picker Picker GE GE
NM NM NM NM
Axis 2000 Axis 3000 Camstar Camstar
1996 1996 1994 1995
None None None
GE
NM Starcam2000
1990
To be replaced in 2003
Link Medical
NM
MAPS 10000
DICOM send/retreive (planned for 2003)
Trust B:
Manufacturer Modality and/or Workstation Model Date of installation Software Version DICOM Service Classes Philips Angio x 2 Inturis SEND,Q/R, HIS/RIS, PRINT Philips CT MX8000 April 2003 SEND,Q/R, PRINT SEND,Q/R, PRINT SEND,Q/R, PRINT HIS/RIS,
Philips
MRI
Intera 1.5T
August 2003
HIS/RIS,
Philips
MXView (x 2)
W/stations
HIS/RIS,
Applicare
Radworks (x 11)
W/stations
V5.1
SEND,Q/R, PRINT SEND, Q/R?
HIS/RIS,
Philips ? (out to tender now)
Nuc Med D.R.
Axis ?
Jun 1998 October 2003
Odyssey V8.9C ?
Trust C:
Manufacturer Modality and/or Model Date of installatio Software DICOM
FINAL 1.0a
Page 331 of 607
ICRS
Workstation GE Toshiba MRI CT GE Toshiba Asteion single slice
n Aug 1998 March 2001 July 2002 Feb 2002 Feb 2000 Feb 2003
Version
Service Classes PRINT/SEND SEND,Q/R, HIS/RIS, PRINT
Toshiba Agfa Agfa Agfa
CT Laser printer Laser printer Laser printer
Toshiba Asteion Multi Slice Agfa Drystar 3000 Agfa Drystar 3000 Agfa Drystar 3000
SEND,Q/R, HIS/RIS, PRINT PRINT PRINT PRINT
Trust D:
Manufacturer Modality and/or Workstation Model Date of installation Software Version DICOM Service Classes Philips Siemens Philips Philips Philips Philips Philips Siemens Philips Toshiba Toshiba ATL Siemens Siemens Siemens Siemens Siemens Philips Bucky room system Bucky room system General X-ray Bucky room system Bucky room system Fluoro system Digital Fluoro Mammo CT US US US US US Mobile Mobile Mobile Mobile Optimus Telediagnost MD3 Mammomat 300 Tomoscan AV T140 Corevision MK9 Antaris G60 x 2 Mobilet Mobilet Mobilet BV29 x 2 1990 1993 2003 1996 1998 2000 1996 1998 1996 1995 1999 1990 1990 1990 1984 1999 2000 1999 5.1.1 4.2.1 1.4j N/A STORE STORE N/A STORE None None None None None N/A N/A N/A N/A N/A N/A N/A
FINAL 1.0a
Page 332 of 607
ICRS
Agfa Kodak Siemens Schimadzu Philips Siemens Siemens IGE Siemens Siemens Accuson Toshiba ATL Philips Philips Siemens Philips
CR Printer General Room Fluoroscopy General Tomo Mobile Mobile Mobile Mammo Dental US US US CT Fluoro Fluoro Fluoro
Compact 2180 AnE Fluoro BTS4 Siremobil AMX4 D38 Mammomat Heliodent 128XP Eccocee HDI 500 LX Diagnost 66 Flurospot H Diag 56
2000 1999 1999 1986 1982 1998 1988 1975 1998 1983 1991 1999 1999 1993 1993 1993 1994
70 -
SEND/STORE/PRINT PRINT N/A None N/A N/A N/A N/A None N/A N/A Frame grabber None None Upgrading Frame grabber Frame grabber
115.9.6
Network Diagrams
Trust A:
FINAL 1.0a
Page 333 of 607
ICRS
Site 2A
Histopathology Pharmacy Secretary's Office Radiology EEG Care of the Elderly Maternity Dental Hospital Biochemistry Pharmacy Ortho Muscular Distrophy Neurology Neuro Radiology
Sluice Room Ward 5
10Mb/s
155Mb/s
10Mb/s
155Mb/s
10Mb/s
155Mb/s
Childrens Outpatients
155Mb/s
155Mb/s
10Mb/s
155Mb/s
Antenatal 10Mb/s 10Mb/s 155Mb/s 10Mb/s Neuro Records Office
10Mb/s
155Mb/s Computer Room
155Mb/s
Nuc Med
100Mb/s
Pathology 155Mb/s 155Mb/s Telephone Exchange 155Mb/s A&E
Haemotology
10Mb/s
622Mb/s
Radiology Wing
10Mb/s
Dental Hospital
155Mb/s 155Mb/s Estates 10Mb/s 155Mb/s 10Mb/s 10Mb/s Outpatients Max Fax
155Mb/s 155Mb/s
155Mb/s
622Mb/s
Main X-Ray
Catering
East Wing
Pharmacy Stores
Ward 6
Switch Room 155Mb/s
64Kb/s
Site 3A
Estates Workshops
155Mb/s
155Mb/s
155Mb/s
155Mb/s
Pathology 64Kb/s
Estates Workshop
Stores
155Mb/s
Treatment
Switch Room
GITU General Office 10Mb/s
155Mb/s
155Mb/s
Cardio 1 155Mb/s
Genetics Institute 100Mb/s 100Mb/s
ENT
155Mb/s
Telephone Exchange
624Mb/s
Podium 10Mb/s
10Mb/s 155Mb/s 100Mb/s Ward Block 1 155Mb/s 155Mb/s 10Mb/s 624Mb/s 624Mb/s Cardio 2 155Mb/s
Cardio 3
Medical Physics
Ward 3
Ward 1
Reproductive Medicine Ward Block 2 Teaching Outpatient Dept. Clinic 155Mb/s Computer Services 155Mb/s Teaching Centre
155Mb/s
Site 4A
Site 4A
Site 1A
File Reference
Teaching Centre
A N Other Hospitals NHS Trust IT Department

Date
Drawn By
Local Area Network Network Schematic - Hub Locations
FINAL 1.0a
Restricted - Commercial and in Confidence
Page 334 of 607
ICRS
FINAL 1.0a
Page 335 of 607
ICRS
FINAL 1.0a
Page 336 of 607
ICRS
Trust C
FINAL 1.0a
Page 337 of 607
ICRS
Trust D
115 - Digital Imaging, including PACS
FINAL 1.0a
Page 338 of 607
ICRS
FINAL 1.0a
Page 339 of 607
ICRS
116 - Document Management Overview This module specifies the requirements for document management. Today a large proportion of care records are held on paper. ICRS will increasingly reduce the amount of paper needed. In some settings, at least, the need for paper could be eliminated if documents could be managed by capturing them electronically and making them part of the Patient Record. Scope Components Document creation and capture; indexing and profiling; file system services/storage; document viewing, annotation and editing; and tracking of paper-based documents and X-ray films.
Benefits and Outcomes To: Patient Improved process and outcomes for patients/clients, resulting in better care because information is available for Clinicians; fewer delays caused by notes not being available; and notes held within a more secure environment than the paper record. Clinician Clinicians/carers have more rapid access to what would have been paper records in the past; reduced turn-around time for some aspects of care as workflow improves, since it does not rely on movement of the paper record; e.g., processing referrals; freehand drawings can easily be included; and the process of audit/research is facilitated. Manager Optimisation of resource time within and across settings; reduced risk of losing evidence in case of legal proceedings; and more space and fewer problems finding notes and filing.
Scenario (a) Managing Joans Chronic Illness and Leg Ulcers Over the last few years, Joans notes (those at the hospital and in the GP practice) had grown to several volumes and there had been problems getting them to the places where she was being treated. Therefore, notes made of contacts at the time were not entered into her notes, or her notes were not available.
FINAL 1.0a
Page 340 of 607
ICRS
Now that her notes are scanned, they can be shared by the team who are caring for her, regardless of which organisation they work in or where she is contacted. Some earlier parts of her record can remain confidential with clear controls; unlike the paper system, which was all or nothing."
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Some communities planning their community-wide document management. Minimum Level to Be Achieved by December 2006 (Phase 2) Some communities planning/implementing community-wide document management. Target for 2010 Where the local health communities can justify the investment and have the appropriate infrastructure, a paperless (or at least paper-light) system can be operated. The need for paper is reduced, anyway, as staff begin to use ICRS rather than the paper record. Overview Requirements Requirement 116.1 Overview Standards for the indexing and profiling of documents will be defined and implemented. The production of documents from the various modules of ICRS producing documents according to those standards (see www.rcplondon.ac.uk/college/hiu/recordstanda rds). Required Response Each bidder shall describe its approach to integrating document management within the ICRS. Specifically in relation to Modules 105, 106 and 107.
Identify any requirements or limitations that might apply to integrating document management solutions with other components of the ICRS. Each bidder shall describe how it would deliver the benefits and outcomes from this module.
116.2
Benefits and Outcomes The service shall deliver the following benefits as described above.
116.3
Implementation and Phasing
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be
The overview delivery expectations have been set o above. More specific implementation ut plans will be agreed with each LSP. 116.4 Authoritys Responsibilities
FINAL 1.0a
Page 341 of 607
ICRS
Requirement
Required Response assumed by the Authority.
Detailed Requirements 116.5 116.5.1 General Requirements The service shall be able to transfer relevant paper clinical records (or parts of records) to an electronic medium for storage. It shall be possible to link the document record with the real time electronic data record and to perform searches across both. The service shall demonstrate compliance to the confidentiality and security requirements, and adhere to legal requirements and extant legislation. The service shall display required images of health records at the clinical workstation/desktop as an integral part of the solution. The service shall be able to record and display the existence of a physical record; e.g., unscanned paper, microfilm, X -ray, as part of the record, and allow a user to request it and track its location. The service shall be stable, resilient and capable of scaling to meet existing volumes of paper and digital records (less those that become due for destruction) and those added during the life of the LSP contract. A coherent and consistent approach shall be taken to facilitate the exchange of records between specialities. The facilities and functions for achieving these links and exchanges (consistent with NHS standards) shall be stated. The service shall allow the facilities established to manage images, wordprocessed documents, e-mail, and other documents that form part of the Patient Record, to be available to the Trusts for nonclinical functions, such as managing Web sites, supporting managerial and administrative tasks, and research and Each bidder shall state how this will be achieved and what constraints there are in its proposed solution to the volume of material stored.
116.5.2
116.5.3
116.5.4
116.5.5
116.5.6
FINAL 1.0a
Page 342 of 607
ICRS
Requirement knowledge management. 116.6 116.6.1 Document Creation and Capture The service shall be capable of scanning individual pages or batches of pages. The service shall enable paper sizes from A6 to A3, of varying colour, weight and quality, to be handled with no detriment to document image quality beyond that of the original. Facilities shall be provided for exceptional documents (such as IDU charts) up to A0 to be scanned. The service shall enable capture of multi-page forms, ensuring that all pages are presented in the correct order. The service shall handle single- or doublesided (long or short edge) pages. The service shall permit the scanning of batches of paper comprised of paper of mixed size and weight. Scanner throughput shall be a minimum of 25ppm. The facility to capture documents in colour shall be provided. Means and procedures shall be supplied for capturing existing records from paper, digital and microfilm stores and allowing the addition of new records from paper and digital sources. The service shall be capable of capturing existing and newly-created records from paper, faxes, e-mails, word-processors, digital photographs, and digital audio and video, and enable them to be stored together in an Patient Record. Users shall be able to search for, display or otherwise retrieve and make use of the files through a standard browser. In the transition period, before all records are available in digital form, the service shall scan a record, on an emergency basis, within 30 minutes of a request.
Required Response
116.6.2
116.6.3
116.6.4
116.6.5
116.6.6
116.6.7
Each bidder shall state the recommended file format and the reasons for its selection.
116.6.8
116.6.9
116.6.10
The means by which this is to be accomplished and any limits upon performance levels shall be stated.
FINAL 1.0a
Page 343 of 607
ICRS
Requirement 116.6.11 The service shall provide the means to enhance captured images, especially where the quality of originals is poor. Resolution The service shall have the ability to control scanned image resolution with contrast control, and must support a resolution range of between 100-600dpi. Optical Character Recognition (OCR) The service shall be capable of supporting bar code, OCR, ICR and OMR functionality. Document Indexing and Profiling Barcode Reading The service shall enable bar codes to be identified and read automatically, regardless of their location on the page, and indexing to be done automatically. Index Field Users shall be able to insert a page or pages into an already existing document in the correct order. The service shall be capable of indexing documents using multiple index fields. The service shall be capable of storing document storage names, with an unlimited number of alphanumeric characters in the name. The service shall enable recently-captured documents to be added to the archive without any degradation to the system responsiveness. The accuracy of indexing shall be validated against demographic data contained in other systems, the validity of which is trusted. The terminology used for indexing specified fields shall be capable of being limited to and validated against that in a controlled
Required Response Each bidder shall describe how this will be achieved.
116.7 116.7.1
116.8 116.8.1
Each bidder shall state what restrictions there are to the deployment of this.
116.9 116.10 116.10.1
116.11 116.11.1
116.11.2
116.11.3
116.11.4
116.11.5
116.11.6
FINAL 1.0a
Page 344 of 607
ICRS
Requirement vocabulary, such as ICD10. 116.11.7 Facilities shall be implemented for free text indexing and for searching digital text documents. It is desirable that facilities are also available to search video and audio files. File System Services/Storage The service shall be capable of outputting images and meta-data held in the repository to any storage media, including RAID, optical disk, fast magnetic disk or WORM. The solution repository shall be capable of holding documents in native format (e.g., ORD) or be converted to industry standard formats for publishing (e.g., HTML, PDF). The solution repository shall be capable of holding more than one version of a document and controlling the rights of users to see all or only the most recently issued version. The system and associated processes shall be certified to PD0008 "Code of Practice for the Legal Admissibility of Image," in support of Clinical Negligence Scheme for Trusts (CNST).
Required Response
116.12 116.12.1
116.12.2
116.12.3
116.12.4
Each bidder shall describe the means by which the system and associated processes may be certified to PD0008 "Code of Practice for the Legal Admissibility of Image," in support of CNST. If there are limitations precluding certification, these shall be stated.
116.12.5
The service shall be capable of storing native XML, managing the security of the individual elements, and assembling and presenting content in accordance with style sheets. Document Viewing, Annotation and Editing The service shall be capable of the easy execution of both simple (within 2 seconds) and complex (within 5 seconds) queries. The service shall be capable of displaying multiple page images simultaneously in a readable font. The service shall have the ability to allow the user to dynamically adjust the sort order as they execute searches.
116.13 116.13.1
116.13.2
116.13.3
FINAL 1.0a
Page 345 of 607
ICRS
Requirement 116.13.4 The service shall enable import and export of image data as standard formats. The service shall be capable of searching on any of the index fields, or a combination of them, to retrieve documents. The service shall be capable of scaling, panning, de-skewing, de-speckling, scrolling, rotating and zooming images. The service shall be capable of sustaining performance when loaded by the projected number of users across the whole care community. This load shall include the addition of newly-scanned content, and the retrieval of records for clinic and ad-hoc searches. The service shall be capable of retrieving and displaying a given page of a multi-page document with no more than 20% reduction in response time from that achieved for a single page document. The service shall allow the display of images in a standard current Web browser with or without encryption. Document Tracking The service shall enable the identification of unscanned paper documents and X -ray films which exist, including the library (home) location of the document and the current location of the document. The service shall enable requesting and tracking of the paper document and/or X -ray film across care settings as required. The tracking record must be updated at each movement out of the library (home) locations well as onwards movements. The service must support individual record tracking, as well as bulk record tracking to enable, for example, the rapid update of bulk record/X-ray movements in and out of libraries or clinic location. The service shall provide facilities to support the effective management of document/X-ray
Required Response
116.13.5
116.13.6
116.13.7
116.13.8
116.13.9
116.14 116.14.1
116.14.2
116.14.3
116.14.4
FINAL 1.0a
Page 346 of 607
ICRS
Requirement libraries, including, but not limited to, flagging of documents which are missing, bulk retrieval/movement of records using different filing protocols, e.g., terminal digit, middle digit numerical, ability to create temporary paperbased casenotes, support for electronic requesting of paper documents, merging of paper records, and management of records for patients notified as deceased. 116.15 116.15.1 Further Requirements The requirement to incorporate paper based records into digital format as part of the ICRS is of particular relevance in relation to social care records. The national Electronic Social Care Record definition is based around a text based document rather than a data record which can be a paper form which has been scanned into a digital format, or could be an electronic text based document incorporating structured or unstructured text based information. This may be a formal document, such as an assessment summary or closure summary, or a less formal record of work in progress such as the record of a statutory visit or audio record of a telephone call. The service shall provide the ability to incorporate the standards applied to the Electronic Social Care Records within the ICRS solution. The standard which is proposed is the ERMS standards published by the Public Record Office www.govtalk.gov.uk/documents/Records_man agement_metadata_standard_2002.pdf. This is specifically designed to deliver the electronic record management standards for government. The set of documents includes a metadata standard, i.e. records about records, which should be used to define exactly what information needs to be held about each record. The key metadata elements held are as follows, within which a number of subelements may be recorded. For further information and detail refer to the documentation:
Required Response
FINAL 1.0a
Page 347 of 607
ICRS
Requirement 1. IDENTIFIER Unique identifier at both object and fileplan (patient) levels. 2. TITLE Title given to record, folder or class. 3. SUBJECT Keywords describing the subject. 4. DESCRIPTION Freetext description of the resource. 5. CREATOR The person responsible for the content of the resource, normally derived from login information. 6. DATE A number of dates in the life cycle of the record, including creation, when acquired, declared, opened and closed. This needs to cover the access trail, see comments below. 7. ADDRESSEE The person to whom a record may have been addressed. 8. TYPE The type of record, this is the level at which the management policy for that record type can be defined. This will include the default record sharing rights. 9. RELATION Identifies relationships between records. Typically where one record needs to be related to another record or one record relates to a number of identifiers (patients) 10. AGGREGATION
Required Response
FINAL 1.0a
Page 348 of 607
ICRS
Requirement Used to define where records management is carried out in the information hierarchy. 11. LANGUAGE The language in which the record is held. 12. LOCATION The physical location of hard copies, artefacts etc. 13. RIGHTS The restrictions and permissions on access to view the record. See notes below. 14. DISPOSAL What will disposed. happen to the record when
Required Response
15. DIGITAL SIGNATURE Definition still under development. 16. PRESERVATION How the record has been preserved through its life cycle. 17. MANDATE The purpose for which the record is held. 116.15.2 Records will need to be accessed in a number of ways including but not limited to: by patient. Covered in the subject of the record. This may need to be a repeatable item as one document may need to be referenced in a number of individual records. For example, a letter from a parent about their 4 children; by date, so that a chronological catalogue of documents can be seen; by source of the record, i.e. who created the record. This would enable identification of all record elements
FINAL 1.0a
Page 349 of 607
ICRS
Requirement produced by specific workers, agencies etc.; 116.15.3 by access/consent type, see section on patient direct access; by record type; and by media type, e.g. video, audio etc.
Required Response
The service shall support the organisation of documents within appropriate sections of the electronic record, including for example: core data; referral, including material related to each referral; assessment, including material related to each assessment; care plan, including material related to each careplan; review, including material related to each review; registers; complaints/complements, with subcategories for specific types of complaints; service info, including providers information, visits and contacts; outgoing correspondence, inc. email; incoming correspondence, inc. email; financial information; risk/health & safety; and archive material.
116.15.4
The service shall support the provision of rules related to each document type. Typically these rules will cover security levels, retention and
FINAL 1.0a
Page 350 of 607
ICRS
Requirement disposal, as well as access rights. 116.15.5 The service shall support the model of information such that access associated with each document type is one of a series of filtered layers: Layer; access controls; and how managed Layer 1 Document creation and indexing; and creation and access rights within application. Layer 2
Required Response
Access controls imposed within the CSSR, e.g. people in adult services are unable to view childrens placement information or adoption records are only available within the adoption team. Normally role defined within CSSR, but may be overridden, e.g. for staff who are also patients. Should be managed within application. Layer 3 Access controls imposed by the CSSR, these may include withholding patient access, rd typically for 3 party information or similar reasons. Defined by information flows as agreed in Caldicott process. Managed within metadata to record changes from the default position. Layer 4 Access controls imposed by the patient. These are the consents to information sharing. Changes made in metadata for each document. Note need only be applied to documents that are subject of information sharing. Patient cannot impose limits on internal CSSR access. Layer 5 Access controls of 3 party organisation, such
rd
FINAL 1.0a
Page 351 of 607
ICRS
Requirement as GP, hospital et al. Normally defined by user management in 3 party agency. It is at this layer the sealed envelope management would operate. This would both prevent access, audit all access that occurs and prompt for justification for overriding any sealed information.
rd
Required Response
FINAL 1.0a
Page 352 of 607
ICRS
117 - Financial Payments to Service Providers Overview This module covers the support required for the calculation of payments that are due to service providers, which are based on the specific care inputs that are provided to individual patients. Scope This module covers: payments (Items of Service) that are due to GPs under the terms of the existing GMS Contract; and payments to independent or private sector service providers, who are commissioned by PCTs and/or their Social Services partners (potentially as Care Trusts or Childrens Trusts) to p rovide services to individual patients.
The module also covers the support required for different payment mechanisms, including: payments based on the achievement of targets; and calculations which must be supported for specific types of provider and services.
This module requires ICRS support to recognise funded events, which may also be used in the monitoring of financial flows between NHS commissioners and service providers. Components This module includes requirements associated with: the calculation of payments due to a service provider for care planned or provided within a particular time period, which may be net of contributions that a patient should make themselves or through a third party, or may cover the whole cost of the care inputs provided; the retrospective adjustment of payments for under- or over-payment as a result of changes in provider prices, patient or third party contributions to care, or notification of variations in care actually provided; the production of payment schedules for export to a financial management system and the import of details of payments made; the calculation of payments due based on the achievement of service targets; the calculation of expenses due to care professionals, which are based on the care inputs they provide to individual patients; and the abstraction of data to enable financial commitments to be monitored and predicted.
This module includes requirements associated with specific types of payments, including: payments to GPs under the existing GMS Contract, covering Items of Service; and payments to the fosterers of "looked after children."
Exclusions This module does not include the production of payment remittances or the aggregate monitoring of financial commitments against budgets, although bidders must indicate how access to this information will be provided to support both the authorisation of care plans and payments.
FINAL 1.0a
Page 353 of 607
ICRS
Other Requirements ICRS must support the details of all care inputs that are planned for a patient, including those to be commissioned from the independent and private sector. ICRS must similarly capture details of all care inputs provided. Benefits and Outcomes Current Situation Support for Items of service payments for GPs is provided through existing GP systems and mandated in RFA 99 v1.2. Existing systems supporting Social Services will have modules to support provider payments, including those associated with fostering of "looked after children." Enable adjustments to payments due under the payment by results system, based on activity delivered. Enable payments to be made for care provided by an NHS provider outside an agreement (OATS replacement). Desired Benefits and Outcomes The provision of this module should: enable improvements in the efficiency of provider payments, by reducing paper-based transactions; support an increase in the choice of service providers available to individual patients, by streamlining the contractual and payment processes for independent and private sector service providers; and improve the management of NHS financial resources and those of joint commissioners by enabling improved monitoring of financial commitments arising out of individual patients' care plans.
FINAL 1.0a
Page 354 of 607
ICRS
Overview Requirements Requirement 117.1 Overview Required Response Each bidder shall describe its approach to supporting the requirements for screening, including the elements that it will supply and the components that it expects to be in place already. Each bidder shall describe how it would deliver the benefits and outcomes from this module.
117.2
Benefits and Outcomes Enable improvements in the efficiency of provider payments, by reducing paper-based transactions. Support an increase in the choice of service providers available to individual patients, by streamlining the contractual and payment processes for independent and private sector service providers. Improve the management of NHS financial resources and those of joint commissioners by enabling improved monitoring of financial commitments arising out of individual patients' care plans. IT systems shall help the NHS to minimise transaction costs by facilitating the introduction of automated invoicing and the generation of draft contract documentation. For efficient invoicing this means linking provider activity/patient care records to accounting and/or contracts departments. In addition, systems for generating draft contract documentation would need to be linked to activity data sets at provider level in order to establish clear baselines and, ideally, forecast indicative growth volumes at specialty and HRG level.
117.3
Implementation and Phasing
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1.
117.4
Each bidder shall describe the responsibilities they would expect to be assumed by the Authority.
FINAL 1.0a
Page 355 of 607
ICRS
Detailed Requirements Requirement 117.5 Calculation of Payments to be Made to Service Providers In order to support the calculation of payments due to providers, the service shall provide access to information covering, for example: the care plans commissioned for individual patients; details of actual care provided to individual patients; details of patient and/or third party contributions; standard rates for the supply of service from independent suppliers, held against the service, for which they are potential contractors; contract details, including payment schedules, prices, details of Accreditation and special allowances for fosterers; financial procedures; and differing approaches to VAT in different organisations. Each bidder shall describe how the calculation of payments to service providers will be achieved. Required Response
117.5.1
117.5.2
The service shall support: the automatic calculation of payments due; and the authorisation of payments by staff with the relevant authority.
In calculating the payment due, actual activity or care inputs provided shall be costed at relevant prices recorded within individual patient service agreements or provider contracts, and shall allow for any patient or third party contributions due. 117.5.3 The service shall support payments associated with individual foster placements, which reflect the characteristics of the child placed, the nature of the placement, and the foster parents' skills or level of Accreditation. It shall allow for regular retainer payments to be made when no placements have been made with an individual fosterer.
FINAL 1.0a
Page 356 of 607
ICRS
Requirement 117.5.4 The service shall support interim payments based on commitments. Subsequent payments may be adjusted to take account of variations. It shall be possible to generate payments covering flexible time periods, paying providers both in advance (based on committed payments), and in arrears (based on actual care provided), or a combination (e.g., payments for 2 weeks; 1 week in advance and 1 week in arrears). The adjustment process shall be undertaken automatically, although there is a requirement to support manual adjustments. The service shall support the comparison of the details of care actually provided by a provider during a given time period with that planned or committed as a result of patient service agreements and contracts. This comparison may be made at the individual patient, service type and/or contract level. This comparison may be undertaken retrospectively, following a payment to a provider based on commitments, and variations highlighted shall be used to calculate adjustments to future payments. Support is also required for the reconciliation of details of actual care provided with invoiced amounts and commitments. The service shall support the capture of: authorisation details (e.g., the date and who is authorising); control information on the payments generated, budget codes, numbers, amounts, etc., to allow reconciliation to financial management systems, as well as dates payment information transferred to financial management systems; and details of the date of adjustments and the staff member initiating the adjustments shall be captured.
Required Response
117.5.5
117.5.6
Each bidder shall describe how this data capture will be achieved.
117.5.7
The service shall: send details of payments to be made to a financial management system to enable understandable remittance advices to be produced; and receive status information on whether the payments have been produced and
FINAL 1.0a
Page 357 of 607
ICRS
Requirement dispatched, and details of the transactions (date, run number, cheques etc.), which shall be maintained against the payment details. This will support staff in answering subsequent service provider queries. 117.5.8 The service shall enable the monitoring of financial commitments against budgets (including those to be commissioned from the independent and private sector) for allocating to service managers to support the commissioning and providing of services. The service shall allow the notional costing of internally provided services (at unit costs) to give an approximate picture of the total cost of care provided. The service shall support the ability to export to, or interface with external systems (e.g. social care systems) to identify actual service delivery events which have taken place during a period which is recorded against a care plan or pathway. The service shall support the ability to cost care plans, incorporating internal and external services, with the ability to store cost limits for guidance against a care plan, interfacing with 2 above, and would also provide the data to output to a social care system. The service shall have the ability to store the assessment of nursing needs (and its reviews) required for individuals in care homes, and interface with the financial payments for such placements. 117.5.12 The services shall enable this information to be extracted or interfaced to an external system (such as a local authority finance system) for budget monitoring. The service shall display information on the service limits for each care community and each care plan/pathway. The service shall enable the identification of the respective care community and/or service provider against elements of the care plan (e.g. healthcare provider, social care, third party, patient).
Required Response
Each bidder shall describe how this will be achieved and if this involves abstraction of data into a separate analysis and reporting module.
117.5.9
117.5.10
117.5.11
117.5.13
117.5.14
FINAL 1.0a
Page 358 of 607
ICRS
Requirement
Required Response
117.6 117.6.1
Payments to General Practitioners The service shall support the capture of details of individual care inputs provided by GPs to patients, which are eligible for specific payment (Items of service). The service shall support staff in calculating the payments due in a given time period, after verification of the care provided during that time period. In the short term, the service shall generate and receive standard items of service Messages used as part of the pre-GMS payment scheme and submit these to external systems as required. Payments Based on the Achievement of Service Targets The details of the information required to support these payments will vary, but support is required for the assembly of information relating to, for example: achievement of targets for the proportion of eligible persons within a population (e.g., registered with a GP or practice), receiving particular services (these may be screening services or specific prevention interventions, such as vaccination and immunisation); changes in the numbers or proportions of persons developing particular conditions; and changes in the numbers or proportions of persons being referred to or admitted to other service providers for treatment/care.
117.6.2
117.6.3
117.7
117.7.1
117.7.2
The service shall provide facilities to manipulate, calculate and combine data from different aspects of a patients care record, and be able to include classifications, care, professional details, etc., including: the ability to set up calculations using formulae and rules, allowing users the flexibility to select a formula and tailor it or reuse it; and the ability to set up standard time periods
FINAL 1.0a
Page 359 of 607
ICRS
Requirement for monitoring. 117.8 Calculation of Care Professionals' Eligible Expenses The system shall enable care professionals to record: 117.8.2 journeys, mileage, date, reason, and budget code mileage and associated to care activity (if appropriate); expenditure, date, reason, and budget code mileage and associated to care activity (if appropriate); and the identity of the user submitting a claim.
Required Response
117.8.1
The service shall: provide facilities to retrospectively add/amend additional mileage and expenses, overlooked at the time of the activity; provide facilities to add mileage and/or expenses that are not specifically related to a care activity; e.g., training; calculate total mileage and expenses; provide facilities to calculate mileage between two locations; and compile expenses/mileage claims for a given time period.
117.8.3
The service shall submit expenses and mileage claims to payroll and/or financial management system.
FINAL 1.0a
Page 360 of 607
ICRS
118 Maternity Overview This module specifies the requirements to support the care of pregnant women and their families throughout pregnancy and into the postnatal period and to support the management of maternity services across all care environments. Scope The general user requirements of this module are: to provide specific health information and education for pregnant women in the community (at home, GP or midwifery clinic or community hospital); and to support community and hospital based midwifery and obstetric care teams so that a high level of equality of community based clinical care is provided as a continuum through the antenatal, peri-natal and post-natal periods.
Components The following components are required: clinical components such as assessment and surveillance, treatment and care planning are to be transferred to the integrated community service (ICS); effective scheduling of antenatal monitoring between ICS and secondary care; patient access to maternity record; planned access to local or tertiary SCBU/NICU and involvement in neonatal care (plan) and ICS support after discharge home (or to local SCBU);the establishment of a link with the MPI, and integration with ICP functionality; observation and monitoring interface; clinical decision support; planned access to local or tertiary SCBU/NICU and involvement in neonatal care (plan) and ICS support after discharge home (or to local SCBU); structured template to include flexible antenatal shared care; share on- and off-line data across care sectors; interface monitors to ICS net work and ICRS; interface with pregnancy websites on PC and digital TV (NHS Direct); and integrate annotation, graphical outputs and management/therapy interventions interface with CPACS and other ICS networks.
FINAL 1.0a
Page 361 of 607
ICRS
Exclusions Generic components provided as part of the ICRS solution will be applied to meet the specific needs of maternity. These needs include assessment, care pathways, clinical noting, clinical correspondence, clinical tools, and telemonitoring mainly located in the community. SCBU/NICU care Other Requirements The service shall have the facility to record care to mothers and baby/babies throughout the whole pregnancy episode and into the postnatal period e.g. from antenatal through delivery, to postnatal wherever the care takes place e.g. in the community setting or in hospital; the babys records shall be linked to the mothers records and vice versa, except in those cases where the mother denies permission for this linkage to be made. There needs to be a mechanism to break / hide this link if the child is adopted; clinical components such as assessment and surveillance, treatment and care planning shall be transferred to ICS; effective scheduling of antenatal monitoring between ICS and secondary care; patient access to maternity record; and increasing foetal and maternal monitoring (cardiotochogram and Doppler and real-time ultrasound will be performed in the ICS supported by tele-monitoring consultation. The reporting requirements such as those required for CEMACH will be collected as a by-product. Dependencies Reliable community-wide broadband network to ICS facilities to give appropriate access from community based settings; and agreement to fully deploy diagnostic and surveillance telemonitoring services into the community.
Benefits and Outcomes Current Situation In general, to date the implementation and adoption of electronic maternity systems has been limited in scope. With a limited number of exceptions, systems have been designed and used for administrative purposes in an organisation-centric manner providing few direct benefits for patient care. Antenatal care is unusual having moved to the community under the changing childbirth policy in 1993, without any infrastructure to support adequate surveillance . Since then it has become clear that inequalities of care and lack of clinical knowledge at the point of care contribute to a high level of undiagnosed fetal growth restriction, and increasing incidence of unexpected stillbirths and poor infant outcomes. This means antenatal care is in special need of ICRS support in the community to provide a base for better risk detection and management.
FINAL 1.0a
Page 362 of 607
ICRS
Desired Benefits and Outcomes The main benefits sought are as follows: the continuum of care for maternity patients across all care settings including the home; confidence and safety in womens choice of pregnancy and birth plan; high level antenatal care in the community for all pregnant women to overcome the inequalities of care for low-risk women and those socially disadvantaged (e.g. teenage pregnancy); better selection and supervision of women wishing to have deliveries in the community; reduction of the inappropriate use of day assessment units and delivery suites in secondary care and redundant use of midwifery and obstetricians time; and strengthening of the patient -midwife partnership by providing access to more information than is currently available to either party.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) 20% of maternity units to use functionality which is integrated within ICRS. Minimum Level to Be Achieved by December 2006 (Phase 2) 75% of maternity units to use functionality which is integrated within ICRS. Target for 2010 100% of maternity units to use functionality which is integrated within ICRS. Requirement Maternity 118.1 118.1.1 General Requirements The service will require all the generic patient care management facilities, but in addition will require facilities to automatically collect data from electronic monitoring equipment. The service shall provide facilities to define the nature of these data transfers as continuous, on ad-hoc instruction, on abnormal occurrences or according to protocols. The service shall support antenatal ultrasonography and foetal medicine management, especially the extraction of serial maternal and fetal growth and physiological development data to provide customised risk Bidders should demonstrate how information from USS and other technology i.e. PACS will be entered into the correct record. Required Response
118.1.2
FINAL 1.0a
Page 363 of 607
ICRS
Requirement profiles. 118.1.3 The service shall record the whole timeline for maternity (antenatal, delivery and post-natal) care in all settings. This will include multiple admissions, transfers, discharges, ward attendances, outpatient appointments/attendance and community care, including home visits. The service shall have the facility to record mothers and baby/babies who receive one or more specified maternity services e.g. antenatal, delivery, post-natal and community. The babys records shall be linked to the mothers records and vice versa, except in those cases where the mother denies permission for this linkage to be made. This link shall be able to be broken if the baby is adopted. The service shall provide the facility to record each maternity assessment wherever it takes place, e.g. in hospital, community clinic or the home using a portable device. Community midwives and other professionals seeing the patient in a community setting shall be able to access the service from a remote location, e.g. a GP Practice. The service shall have the facility to record maternity care involving mother and baby from all settings e.g. home, community clinics and hospital. The service will require all the generic patient care management facilities, including facilities to automatically collect data from electronic monitoring equipment. The service shall provide facilities to define the nature of these data transfers as continuous, on ad-hoc instruction, on abnormal occurrences or according to protocols. Antenatal Data Items The service shall collect past and current medical, surgical, social, psychiatric, family (including abnormalities), obstetric (including previous baby details and miscarriage) and menstrual history.
Required Response
Bidders should demonstrate how the record will be completed from different care settings.
118.1.4
Bidders should demonstrate how this link is made and can be separated.
118.1.5
Bidders should demonstrate how the record is accessed by peripatetic staff who are not able to access a static device.
118.1.6
118.1.7
118.1.8
Bidders should demonstrate the information flow and collection process here.
118.2 118.2.1
FINAL 1.0a
Page 364 of 607
ICRS
Requirement 118.2.2 The service shall support the clinical noting of all examinations including those relevant to generic patient care and those which are specific to maternity. The service shall have the facility to record all antenatal assessment unit activity including: 118.2.4 BLT 24 hr ambulatory BP monitoring; and Fetal and maternal Doppler blood flows and CTGS.
Required Response
118.2.3
Bidders should explain how this information is entered into the record.
The service shall have the ability to record the type of care e.g. midwife lead shared care, hospital and any change to the type of care. The lead professional must be recorded. The service shall have the facility to print customised fundal height charts. The service shall provide the facility to calculate Downs risk using either an algorithm with the st Nuchal Translucency measurement or Pap A 1 trimester screening in conjunction with the pathology system. Labour/Delivery Data Items The service shall provide data for an appropriate electronic display in delivery suites with real time updates on care in each room. An example of such a display would be an electronic whiteboard screen. The service shall provide direct access to any or all antenatal maternal fetal monitoring events, especially CTGs, Doppler measurements for decisions in labour management. An interactive care screen shall incorporate decision support using data from monitoring devices, CTG, BP monitoring combined with other EPR information.
118.2.5
118.2.6
118.3 118.3.1
118.3.2
118.3.3
The service shall record details of the staff present during the delivery (names, status and role).
FINAL 1.0a
Page 365 of 607
ICRS
Requirement 118.3.4 The service shall have the facility to record the actual place of delivery including the room number if applicable and record the reason for change if this is different from the intended place of delivery. The service shall have the facility to record and time and date stamp the process of labour and delivery wherever labour is occurring (e.g. home or hospital) including, but not restricted to: type of monitoring in labour; type of onset of labour; augmentation reason and method; induction reason and method; rupture of membranes including type; colour of liquor at rupture and delivery; delivery method and reason in particular for instrumental, ventouse and caesarean section deliveries and other interventions during delivery; and any complications in labour, delivery or in the immediate post-natal period.
Required Response
118.3.5
118.3.6
The service shall allow the progress of labour and delivery to be entered in real time wherever labour is occurring i.e. home or hospital. The service shall provide facilities for calculating the duration of any of the events in the labour/delivery process at all stages. The service shall provide facilities to produce and display Partogram graphic data on request. The service shall be able to record details of the third stage of labour, including but not restricted to: method; state of placenta and membranes; number of vessels in the cord; Bidders should explain the links with pathology so that an abnormal reading will be alerted.
118.3.7
118.3.8
118.3.9
FINAL 1.0a
Page 366 of 607
ICRS
Requirement estimated blood loss; any blood transfusion; record cord blood taken (the service shall record Cord blood outcome direct from machine); record maternal blood taken; and record weight of placenta and abnormalities.
Required Response
118.3.10
The service shall have the facility to record the state of the perineum (with ability to make multiple selection) including but not restricted to: repair of the perineal area; material used; the name and status of the recorder; if they are under supervision, the name and status of the supervisor; and validation for items such as number of sutures if a third degree tear has occurred i.e. it cannot be zero in this case.
118.3.11
The service shall be able to record anaesthetic details including: the type of anaesthetic during labour, at delivery and after delivery; the type of anaesthetic post delivery; complications of the anaesthetic techniques used (if any); and if an epidural has been given, the service shall record if the epidural catheter has been removed and alert the user if not.
118.3.12
The service shall have the facility to record details of placenta delivery for LSCS and skin suture for LSCS. The service shall keep maternal and baby items separate so that multiple births can be entered sequentially.
118.3.13
FINAL 1.0a
Page 367 of 607
ICRS
Requirement 118.3.14 The service shall have the facility to record details of the foetus/baby (single/multiple births), including: 118.3.15 the presentation of the foetus at delivery and position of presentation; shoulder dystocia including the procedure or manoeuvres required to resolve it; gender of the baby; gestational age; estimated date of delivery from antenatal record; birth weight; head circumference; temperature; umbilical cord artery and vein blood gases etc.; maternal blood chemistries as required; type of neonatal resuscitation given; APGAR score at 1, 5 and 10 minutes; elapsed time respirations; before onset of regular
Required Response
immediate neonatal problems; suspected congenital anomalies; intended method of feeding; and type of first feed.
The service shall have the facility to record stillbirths and intra-uterine deaths including date, time, gestational age and related details e.g. weight, head and chest circumference, antepartum, intrapartum and other stillbirth. The service shall have the ability to record terminations of pregnancy, including the reason
118.3.16
FINAL 1.0a
Page 368 of 607
ICRS
Requirement for and method of termination. 118.3.17 The service shall have the facility to record the in utero and ex utero transfer of mother, baby/babies to other units or wards including ITU, Critical Care and Coronary Care. The service shall have the facility to record all patients requiring high dependency and, where appropriate, intensive care within labour ward and delivery suite. Post-Natal Data Items The service shall have the facility to record any maternal postnatal complications, whether they occur in hospital or in the community. The solution is required to allow the recording of all normal post natal interactions, including the issue of public health advice. The service shall allow the mother and baby/babies to be transferred home separately or together. The service shall have the facility to transfer information to all relevant health and social care professionals for continuing care e.g. GP, HV, social worker. Antenatal Completion The service shall have the facility to record any pregnancy which results in a miscarriage or intrauterine death, including but not restricted to: date and time; gestational age; type of miscarriage; treatment; any related management of the miscarriage; and complications.
Required Response
118.3.18
118.4 118.4.1
118.4.2
118.4.3
118.4.4
Bidders should explain how information transfer is facilitated.
this
118.5 118.5.1
FINAL 1.0a
Page 369 of 607
ICRS
Requirement 118.5.2 The service closure of continue on all pending cancelled. shall have the facility to record the any pregnancy, which does not to delivery for other reasons and for appointments and actions to be
Required Response
118.5.3
The service shall provide details of the examination of the stillbirth and abortion including date and time, post mortem required, cause of death and the name of the person carrying out the examination as part of the core record. Other Data Collection Requirements (see also Section 975) The service shall provide facilities to capture, display and automatically report on all the data items included in the Maternity national datasets. The service shall support a dynamic link to obtain a new NHS number in real time which is invisible to the user. The service shall produce a hand held pregnancy record which can be updated throughout the pregnancy and issued to the mother. It may be necessary for health services elsewhere to be able to view the local record of care, having identified the patient and requested the view. The service shall allow a record to be kept of booked mothers who are transferred out elsewhere for delivery due to lack of beds. This would be vital information in terms of organising the service and resource allocation. Neonates The service shall record details of the paediatric examination on admission to the Neonatal Unit. The service shall have the facility to record any neonatal complications, whether they occur in hospital or in the community. The service shall allow outcomes to be measured against observations made during antenatal care. The service shall record all congenital abnormalities and dysmorphic features. Each bidder shall describe how this will be achieved.
118.6
118.6.1
118.6.2
118.6.3
118.6.4
118.7 118.7.1
118.7.2
118.7.3
118.7.4
FINAL 1.0a
Page 370 of 607
ICRS
Requirement 118.7.5 The service shall be able to record the full first examination of the newborn including head, face, and eyes, musculo-sketal, cardiovascular and CNS system. The service shall have the facility to record the actual method of feeding on discharge from hospital and on discharge from care by the community midwife. The service shall have the facility to record the weight of baby/babies at discharge from hospital and on discharge from care by the community midwife. The service shall have the facility to record the discharge outcome of baby/babies from hospital and send an electronic notification of the discharge to the appropriate Child Health services, Health Visiting team and to the mother's GP. The service shall link antenatal, intrapartum and neonatal developmental and physiological monitoring data to further milestone measurements in infancy.
Required Response
118.7.6
118.7.7
118.7.8
118.7.9
FINAL 1.0a
Page 371 of 607
ICRS
119 - Social Care Overview Overview of Requirement The purpose of the requirement for social care is to define how generic functionality needs to be applied to support social care processes and to define those specific requirements which relate to social care that are not covered by generic functionality. In particular, this will include the different mechanisms which will be required to support joint working between health and social care. At a national and local level developments in health services are moving towards a more integrated, holistic approach to providing healthcare both in terms of health prevention and healthcare. The interface with social care services is seen as an integral part of this process particularly with regard to Mental Health, Older persons, and children at risk (not forgetting other adult groups with physical and learning disabilities etc.). For these specific areas the continuity of care whether this is provided by health or social care professionals is critical in delivering some of the national policy objectives enshrined in NSFs, the NHS Plan, Shifting the Balance of Power and emerging policies concerning protection of children at risk. Many of the failures of joint working have been evidenced in national enquiries and these invariably have high profile (e.g. Climbie Inquiry). In most cases the failure to exchange/share information between professionals is one of the causes of failure. ICRS shall therefore support improved processes of communication and integrated working between health and social care. Social Care is generally a service, which is provided by Social Services professionals employed by local authorities with a substantial proportion of the actual c lient service being provided by the independent sector. There are, however, Care Trust organisations emerging which combine the responsibilities of health and social care service provision within one organisation, and new Childrens Trusts will further develop this concept. In the main the provision of social care services is the responsibility of local authorities. There are equally important relationships with Education, Housing and Youth Justice services, amongst others, and social services provide a critical interface between health care and these other services. Inter-working between social and health care is a developing agenda alongside the increasing community focus within health. Integrated working between health and social care agencies is not yet mature. The Single Assessment Process while a defined integrated approach across health and social care is still experimental. The current mulitplicity of systems and organisations have resulted in a variety of joint approaches. ICRS will provide a more consolidated provision of services to support care processes. However, within social services there will continue to be multiple systems into the future. The interface between health and social care can range from health and social care professionals working seamlessly as part of a unified multi-professional team (or virtual team) to a more distinct but linked approach to meeting the combined health and social care needs of patients. Module 770 Clinical Communication, will help to support these interfaces.
Electronic social care record developments There is currently a DoH working group looking at the definition of Electronic Social Care Records (ESCR). The emphasis for ESCR is based largely around document management as opposed to a structured data level record consistent with ICRS, although ESCR and ICRS are both to a certain extent concerned with data level and document based electronic records. As part of the work on the ESCR the use of document standards are being applied based on the Public Record Office,
FINAL 1.0a
Page 372 of 607
ICRS
Electronic Records Management Systems standard which incorporates metadata information which defines and attributes each document within the ECSR (see www.govtalk.gov.uk). This is expected to provide exchange of information between the wide variety of social care systems (there are probably 5 or so major players in the market, with a wide variety of home grown systems as well). Similar exchange of information will be required with care organisations and therefore ICRS will need to accommodate these emerging document standards in order to support exchange of information critical to integrated working e.g. SAP.
Types of joint working and interfaces The minimum level of support which will be required will involve interfacing and messaging between health a social care systems and for some specific care processes, shared access by health and nd social care to ICRS functionality. The actual deployment of these different mechanisms is likely to be specific to each local authority and the health communities which they serve. The solution therefore shall support not only different mechanisms for supporting integrated health and social care but shall also provide flexibility in the way in which this is deployed within health and social care communities which comprise the cluster. Five specific mechanisms of interaction between health and social care have been identified: Shared functionality (unified working) for certain integrated health and social care processes there will be a requirement for social care staff to use the functionality of ICRS directly in management of a client/patients social care requirements. An example of this will be mental health where the integrated care processes to support the Care Programme Approach and Care Management require a closely integrated approach between health and social care. An interface may also be required to pass information recorded within the ICRS record to social services systems to enable social service specific returns and processes to be supported. This method may have a developing role for the Single Assessment Process, but there could be major interface elements around the commissioning and charging for care. Information exchange interface between social care systems and ICRS. The complexities of social care require that some integrated health and social care processes are supported through sharing of information between health and social care but that recording of data is retained within distinct application systems. An example of this may be work with people with a learning disability, where the majority of work can be around dealing with their social care, but this needs to be co-ordinated with ongoing work from health practitioners (who may also be recording on a social care system). However, the data items which are collected as part of the assessment process in social care must be shared with other health care professionals and must comprise part of the assessment record in the ICRS. It should be noted that much of social care information is document/form based and the incorporation of different data formats will be required within ICRS as part of these processes. Where material is to be exchanged between systems, a secure extranet may be a requirement. A critical feature of this is an audit trail of material transferred. Access to data held in disparate systems there is a requirement to support access to specific data held within social care information systems by healthcare staff, which needs to be supported by ICRS. An example of this may be access to the Child Protection Register which is managed and maintained by social services but authorised access is required by healthcare staff. This may be access provided through an extranet facility. It needs to be real time and will require a record of access to be recorded against the social care system as an audit. Similarly social care practitioners may need to access ICRS data in specific circumstances (e.g. emergency handling of a mental health patient)
FINAL 1.0a
Page 373 of 607
ICRS
Structured and unstructured messaging there are many situations where communication between health and social care needs to be supported through notification of defined or undefined events, incidents or concerns about a client/patient. There needs to be a facility within ICRS to create, dispatch, and receive structured and unstructured messages, which may or may not be encrypted. Messaging, secure email and fax communication needs to be supported. Systems will need to be able to embed these e-mail exchanges as critical elements of clinical recording. This mode may be technically associated with the information exchange cited above. On-line data exchange, where an on-line facility enables transfer of material from one system to another (e.g. name, address, equalities information), which can help ensure consistency of data in linked systems.
Scope The services which are provided by Social Services include: adult services; and childrens services.
Like much of primary and community care, social care is a mobile delivery profession, and an infrastructure that supports mobile working is of real value. While interfaces and joint working cover all client groups, the key areas of integrated care between health and social care are concerned with management of care services for: older persons; mental health patients; children, particularly children at risk; and learning disabilities.
A distinction can usefully be made between the care processes which support adults and those which support children. Adult processes may be more amenable to joint work within ICRS (as the processes are mandated to be joint by the DoH), while Childrens processes are best done through the interchange of information (given the wider role of the local authority as protector and parent). This may cause some problems on transition from childhood. Consent and Caldicott issues - There is not much difference in terms of consent and confidentiality issues between health and social care, with the exception that the public are less likely to want people sharing material across the boundaries than they are within the sectors partly due to a social stigma around social care (as there is around elements of health care like mental health or sexually transmitted diseases). The document put out for consultation by the NHSIA is largely agreeable to social care, but the key element will be about clinicians/practitioners enabling the patient to provide informed consent about the sharing of information, and the ability to lock material in a secure envelope where this consent is not given without prejudicing the integral nature of the system in process terms. Consent issues can become more interesting for children and people with learning disabilities judging whether they can consent in an informed manner, and who has the right to do it on their behalf. These issues can be more complex when information is being exchanged by computer.
FINAL 1.0a
Page 374 of 607
ICRS
Management Information Where processes are created in ICRS, then the system shall also provide the statutory and local management information that goes with those processes (e.g. RAP returns), or should provide interface information to social care systems to enable information to be reported externally to ICRS. The requirements for Social Care will be met through the application of the generic functions specified in Module 101 - User Tools to Module 125 Surgical Interventions. It is not the intention that any separate systems would be supplied to meet the social care needs. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of Social Care. In each case, reference has been made to relevant generic modules.
Specific NSF Requirement for Mental Health
The bidders must show that the specific requirements are dealt with and the generic ICRS functions below will give a guide.
119.1 119.1.1 The service shall support the ability to create mainly textual records, or upload them from word processing or scanned documents, while providing key statistical and control fields around them (like event start and end dates). Such assessments shall be surrounded by document management standards (ERMS standards is the emerging standard which will be adopted by social care). The service shall provide the ability to receive text based records and such assessments from external systems and embed them in the record, including the workflow, as detailed below. (For example, part of the workflow could take place outside ICRS, and the result be posted back into ICRS, which sets the workflow going again). The service shall have the ability to save incomplete documentation (e.g. missing information which is unavailable at the time) for editing later. Documents once completed shall prevent editing except under strict audit control. Incomplete documents shall not be notified to the Spine, only complete documentation should be sent to the NHS Spine record. 119.1.4 The service shall enable the individual responsible for co-ordinating a specific programme of care to be identified and for summary assessments and review information 104 Assessment 105 Integrated Care Pathways and care Planning 104 Assessment 116 Document Management
119.1.2
101 User Tools 104 Assessment
119.1.3
104 Assessment 116 Document Management
FINAL 1.0a
Page 375 of 607
ICRS
The bidders must show that the specific requirements are dealt with and the generic ICRS functions below will give a guide.
to be notified. 119.1.5 The generic functionality defined around workflow for ICRS services shall support specific requirements around the process of referral, assessment, care plan, review and closure (with the middle three elements of the process recurring). The service shall include the ability to track timescales between the elements, and the ability to show items by the next process due, and how long it has been waiting. The service shall enable the setting of default standard and maximum dates for elements of this processing (which may vary by care community or local authority boundary). Within this workflow, there may be other assessments commissioned and recorded. The service shall have the ability to distinguish these more specific assessments and the workflow around them, within the context of the major process. The service shall provide the ability to export key events (configureable) as documents to external systems, using document management standard descriptions around the document. The service shall provide the ability to monitor hospital discharge and the provision of community packages within the assessment process, and provide information for the charging of delayed discharge to the local authority. In relation to mental health, the service shall be able to link the administration of compulsory sections of the Mental Health Act with the concepts of assessment and review processes. The service shall provide the ability to structure a care plan mixing internally and externally provided services, detailing the quantity, times and regularity of services (including start and proposed end dates). This will include the identification of resources which are awarded to patients to enable direct purchase of their own care. 101 User Tools 104 Assessment 105 Integrated Care Pathways and care Planning
119.1.6
116 Document Management
119.1.7
104 Assessment 105 Integrated Care Pathways and care Planning
119.1.8
104 Assessment (See also 161 Mental Health)
119.1.9
105 Integrated Care Pathways and care Planning
FINAL 1.0a
Page 376 of 607
ICRS
The bidders must show that the specific requirements are dealt with and the generic ICRS functions below will give a guide. 105 Integrated Care Pathways and care Planning
119.1.10
The service shall provide the ability to communicate individual elements of the care plan to the different suppliers of service, and provide all other appropriate information at the same time (dependent on the type of service). The service shall be able to identify elements of the care plan that are social care and export these to external systems in a standard format. The service shall support the ability to refer on from ICRS to external systems with relevant material (e.g. to benefits or supported housing services) with a structured message using, for example, e-mail as the transport mechanism. Social Care Information to be Available on the Spine Record The services shall enable child protection information to be stored and provided to the Spine under strict security control, and allow professionals to link events to child protection concerns and referrals (routed urgently to relevant people in social care). This should appear as an alert on the NHS Spine record. The services shall have the ability to store warning information on dangers to staff and others on the Spine, linked to incidents, which gave rise to this recording. The service shall provide a service by which such warnings are regularly reviewed for appropriateness. There shall be a formal review mechanism assigned to the warning to ensure warnings are valid and timely. The service shall have the ability to create and record structured and unstructured messages and route these to designated recipients, some of which may be external organisations. A timescale for response and whether a response is urgent is also required with an alert generated when the timescale is exceeded.
119.1.11
105 Integrated Care Pathways and care Planning
119.1.12
106 Clinical Documentation
119.1.14
106 Clinical Documentation 121 Maintain Patient Details
119.1.15
121 Maintain Patient Details
119.1.16
FINAL 1.0a
Page 377 of 607
ICRS
The bidders must show that the specific requirements are dealt with and the generic ICRS functions below will give a guide. 121 Maintain Patient Details
119.1.17
The service shall support the identification of specific patients such as looked after children or children on the disability register, so that messages are communicated to relevant communities when key events happen. The service shall include pertinent information such as the local authority and social worker contact who may need to give permission for treatment in an emergency.
119.1.18
The service shall have the ability to identify unborn children (potentially in need of protection), and after death (where social care may need to arrange funerals and deal with estates).
121 Maintain Patient Details
FINAL 1.0a
Page 378 of 607
ICRS
120 - Dental Services Overview
This module specifies the requirements for the Service to support the delivery of dental care within the primary and secondary care sectors. Scope To support the provision of primary and secondary dental services within the NHS. (Note to Bidders: there will be a mix of NHS/private dentistry provision in primary dental care.) Components The Service shall record information including the condition of the patient, medical/dental history, special requirements, treatment details, diagnosis, tests and technical work required. The Service shall provide user-interfaces suitable for the dental setting (e.g. tooth charting, oral mucosal maps etc), which should be encoded, where appropriate, to the NHS standard clinical terminology. Other Requirements The Service shall support the use of treatment aims and treatment plans, whose details will need to be entered in more than one stage. A treatment plan history must be maintained and shall include the detailed requirements listed below. In time, the Service should provide support for NHS Clinical Care Pathways for dentistry (including an oral health assessment) and information requirements for the new models of remuneration that are currently in development. Dependencies NHS Dentistry: Options for Change field-sites: http://www.doh.gov.uk/cdo/optionsforchange/index.htm. NHS Dentistry IT Strategy http://www.doh.gov.uk/ipu/whatnew/dentalitstratoct2002.pdf Development and information requirements of NHS Clinical Care Pathways for Dentistry Health and Social Care (Community Health and Standards) Bill. NHS Network Connectivity for dentists particularly in the primary dental care services Population of dental practice registers with NHS Number with the use of the NHS Number as the patient identifier in dentistry eBookings
Current Situation: Primary dental services There are over 18,000 dentists working in 9,000 practices in England. There is already significant use of IT in primary dental services but there is very limited use of either NHSnet or NHS Number. Dental systems are not within the scope of Requirements for Accreditation (RFA). A major use of IT in primary dental care is the EDI x400 link for item of service claim
FINAL 1.0a
Page 379 of 607
ICRS
transmission to the Dental Practice Board (DPB). 60% of NHS item of service claims data is transmitted in this way. It has been estimated that 70% of the number of dental practices in England are using computers for some aspect of dental practice management. Acute dental services Maxillofacial surgery and orthodontic treatments are carried out in many acute units. There are also a limited number of hospitals with Restorative and Paediatric Dentistry specialist units. Dental hospitals There are 11 dental teaching hospitals and approximately 1.2 million patient treatments a year. Dental hospitals also provide the location for dental services for secondary and tertiary referrals from general dental practitioners (GDPs), including patients with special needs. Desired Benefits and Outcom e s The inclusion of a dental module in ICRS will provide benefits for: patients: by integrating dental records with the mainstream ICRS the NHS: by providing economies of scale (e.g. in procurement and the delivery of integrated systems). dentists: as they will be able to take advantage of other NHS IT initiatives (e.g. eBookings and sharing of records). Trusts and SHAs: as LSPs, will be able to provide dental systems that link with other healthcare systems.
Minimum Level to Be Achieved by December 2004 (Phase 1) Consultation with dental professions, system suppliers and other stakeholders (e.g. PCTs, Dental Practice Board on ICRS) Limited record sharing between dental and ICRS-based systems Plans and timescales for the integration of dental systems within ICRS Significant increase in the use of NHS Number as the patient identifier in dental systems Clarification of the procurement mechanisms for dental systems within national models Significant increase in the number of dental practices connected to NHSnet
Minimum Level to Be Achieved by December 2006 (Phase 2) Support for NHS Clinical Care Pathways Support for information requirements to support new methods of remuneration and performance management (including messaging to PCTs, Dental Practice Board etc)
FINAL 1.0a
Page 380 of 607
ICRS
Increased levels of record sharing between dental and ICRS-based systems
Target for 2010 Full integration of dental services with all other components of the ICRS
Overview Requirements Requirement 120.1 Overview Required Response Each bidder shall describe its approach to integrating dental services within the ICRS. Each bidder shall identify any requirements or limitations that might apply to integrating dental services with other components of the ICRS. 120.2 Benefits and Outcomes The expected benefits and outcomes have been set out above (Desired Benefits and Outcomes) 120.3 Implementation and Phasing The overview delivery expectations have been set out above. (Delivery Expectations) More specific implementation plans will be agreed with each LSP. 120.4 Authoritys Responsibilities Each bidder shall describe how it would deliver the benefits and outcomes from this module.
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it is able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
Detailed Requirements Requirement 120.5 120.5.1 General The Service shall record basic treatment details such as the priority for treatment. Other treatment details, diagnosis, tests and technical work required shall be added by users when the patient attends for treatment. Each bidder shall indicate how it will meet this requirement and how this integrates with the generic functionality. Required Response
FINAL 1.0a
Page 381 of 607
ICRS
Requirement 120.5.2 The Service shall provide an assessment screen (including orthodontics) to record the condition of the patient as well as medical/dental history and special requirements and shall automatically suggest a set of clinical codes. The Service shall provide the ability to record data on the condition of patients oral health including teeth, periodontium (gums), orthodontics, oral mucosa and prostheses. The Service shall include initial planned treatment details, including: 120.5.5 Special requirements (e.g. whether a sedation facility is required). Treatment complexity/peer assessment rating. Earliest treatment start date. Procedures to be undertaken. Number of appointments. Duration between appointments. Length of visit for each appointment. Procedures to be undertaken at each appointment. Suitability for a named clinician.
Required Response Each bidder shall indicate how it will meet this requirement through its part in the generic assessment function (Module 104 - Assessment).
120.5.3
Each bidder shall indicate how it will meet this requirement through its part in the generic assessment function (Module 104 - Assessment). Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning).
120.5.4
The Service shall provide a tooth map for the identification of individual teeth & their surfaces and dental chart tracking
Each bidder shall indicate how it will meet this requirement through its part in the generic assessment function (Module 104 - Assessment). Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning).
120.5.6
The Service shall support the use of treatment aims and treatment plan, whose details will need to be entered in more than one stage. A treatment plan history shall be maintained and shall include: Clinical examination Special investigations (tests) required. Diagnosis. Revised, itemised treatment details. Hygienist/therapist and professionals complementary to dentistry required. Technical work required.
120.6
Treatment Aims
FINAL 1.0a
Page 382 of 607
ICRS
Requirement 120.6.1 Users shall be able to use standard care profiles/Clinical Care Pathways as templates to allow work to be done to include number of appointments, duration between appointments and length of visit for each appointment and shall also allow clinical management requirements. The Service shall support the use of the treatment plan to describe proposed treatment through a clinical coding structure as well as the use of a management plan that will preview a series of appointments needed to complete the said treatment and shall provide all the information necessary to allow the user to book appointments for the patient. The Service shall support the use of care profiles, which will outline the dental services to be provided for that patient group including: Number and type of X-rays to be performed. Digitised images storage/retrieval/messaging of such images Number and type of pathology tests to be performed. Number and type of technical work to be undertaken. Number and type of dental procedures. Classification of clinician. Number and type of prescriptions for dental hygienist treatment. Intensity of nursing required. Duration of patient attendances with relation to treatment. Number of patient attendances with intervals between, related to technical work program and hospital scheduling. Re-referral rate. Required outcome. Total elapsed time for treatment.
Required Response Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning) using the appropriate support and Module 112 Decision Support). Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and care Planning).
120.6.2
120.6.3
Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning).
FINAL 1.0a
Page 383 of 607
ICRS
Requirement 120.6.4 The Service shall provide warnings and alerts when there is a requirement for a health professional to be chaperoned or not to do exposure prone treatments in relation to a particular patient.
Required Response Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning) and its decision support mechanism (Module 112 Decision Support). Each bidder shall indicate how it will meet this requirement.
120.6.5
The Service shall be able to support NHS Clinical Care Pathways for Dentistry (when available). Chair Management The Service shall provide all the functionality to support management of dental chairs
120.7 120.7.1
Each bidder shall indicate how it will meet this requirement through its part in management of resources within Module 107 Care Management.
120.8 120.8.1
Facilities The Service shall support time allocation for the provision of antibiotics. Each bidder shall indicate how it will meet this requirement through its part in workload planning. (Module 101 User Tools). Each bidder shall indicate how it will meet this requirement through the generic process (Module 104Assessment). Each bidder shall indicate how it will meet this requirement.
120.8.2
The Service shall be able to provi de patient clinical history on screen, in either summary format or as full chronological treatment history for a tooth and/or supporting tissues. The Service shall have the ability to compare pre-treatment and post-treatment stages in computer simulations. The Service shall support differentiation between planned and completed treatments and present them to the user accordingly. What-if scenarios shall be supported. The Service shall have the ability to enter, record, view and manipulate dental tooth charting (periodontal charting, oral medicine mouth map, partial denture design and other user-required charting).
120.8.3
120.8.4
Each bidder shall indicate how it will meet this requirement.
120.8.5
Each bidder shall indicate how it will meet this requirement through the generic process (Module 104 Assessment).
FINAL 1.0a
Page 384 of 607
ICRS
Requirement 120.8.6 The Service shall support any image manipulation (e.g. enlargement, angle change, change of tooth or mouth site and part; contrast, brightness, filling in, drawing). The Service shall have the ability to support tracking of instruments used by a clinician / student for a patients examination/treatment. The Service shall have the ability to support speciality-related graphical representations. (e.g. tooth maps and anatomical pictures of the mouth). The Service shall have the ability to allocate individual patients to a particular student and enable the patient to be reallocated when the student leaves.
Required Response Each bidder shall indicate how it will meet this requirement through the generic process (Module 115 Digital Imaging). Each bidder shall indicate how it will meet this requirement.
120.8.7
120.8.8
Each bidder shall indicate how it will meet this requirement through the generic process (Module 101 User Tools). Each bidder shall indicate how it will meet this requirement through its part in generic care planning. (Module 105 Integrated Care Pathways and Care Planning). Each bidder shall indicate how it will meet this requirement.
120.8. 9
120.8.10
The Service shall enable the transfer of Patient Records between dentists and organisations such as, but not limited to, NHS Trusts. The Service shall connect to the NHS Network. The Service shall have the ability to support new models of remuneration (when available) but continue to support the existing Item of Service claim / activity returns submissions to the Dental Practice Board for as long as these are required.
120.8.11
Each bidder shall indicate how it will meet this requirement. Each bidder shall indicate how it will meet this requirement.
120.8.12
FINAL 1.0a
Page 385 of 607
ICRS
121 Maintain Patient Details Overview This module specifies the requirements for the Service to support the maintenance of basic patient information which will be used in patient care. In most patient encounters, information about the patient may be gleaned. This module provides the mechanism to maintain this data. Data relevant to the generic care functions shall be dealt with within each of those functions (e.g. in Module 104 Assessment). Similarly, data retained within a service which is provided on a national basis (e.g. the Personal Demographics Service) will not be captured through this module. Data shall never be deleted and may be superseded or logically struck-out rather than deleted. Scope Support for the maintenance of a patients basic health and social history. Support for documentation of basic carers details
Exclusions Data maintained within other National Services (e.g. the Personal Demographics Service) Data maintained through other generic processes (Assessment)
Benefits and Outcomes Current Situation Most, if not all, current clinical systems provide mechanisms to capture and maintain basic patient details. Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1)
To provide all the requirements specified in this module 121.

Minimum Level to Be Achieved by December 2006 (Phase 2)

Target for 2010
FINAL 1.0a
Page 386 of 607
ICRS
Overview Requirements Requirement 121.1 Overview The core requirement is a service which allows basic and essential data about a patient to be maintained. 121.2 Benefits and Outcomes As described above (Benefits and Outcome). 121.3 Implementation and Phasing The overview delivery expectations have been set out above (Delivery Expectation). More specific implementation plans will be agreed with each LSP. Required Response Each bidder shall describe its approach to delivering the support for delivery of the patients basic data maintenance.
Each bidder shall describe how it will deliver the benefits and outcomes from this module. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it shall deliver during Phase 1. Each bidder shall describe responsibilities it expects Authority to assume. the the
121.4
Detailed Requirements Requirement 121.5 121.5.1 Maintain Basic Patient Details The Service shall provide a confidentially appropriate mechanism to maintain, add and replace) patient summary data. This data shall include: alerts / risk highlights (including both risks to the patient and to care staff from the patient) patients personal preferences (e.g. preferred language) patients special needs (e.g. dietary requirements) patients allergies, sensitivities, intolerances, adverse reactions including whether clinically validated and level and type of response/reaction patients health problems patients health history (e.g. historical contacts with the care services) including diagnoses, procedures and assessments The Bidder shall describe their proposed facilities to provide this functionality. Required Response
FINAL 1.0a
Page 387 of 607
ICRS
Requirement (e.g. registered partially sighted) patients social history (e.g., social circumstances, alcohol and smoking habits, spiritual needs); patients obstetric history; patients activities of daily living; patients functioning (e.g. mobility); patients family history patients family relationships including nongenetic relationship flags (subject to sealed envelope requirements where appropriate) Values should be coded wherever a relevant standard coding system is available and approved for use in this context by the NHS Design Authority 121.5.2 The Service shall allow, for each item of patient related data, the source of the data to be recorded. This shall include: the person providing the data, their role and organisational context; the date the information was provided; whether the information was provided by a third party and, if so, the relationship of the third party to the patient.
Required Response
The Bidder shall describe their proposed facilities to provide this functionality.
121.6 121.6.1
Maintain Basic Care Relationships The Service shall provide a facility to maintain all the basic care relationships for a patient. This shall include : carer details registered General Practitioner (GMP) registered General Dental Practitioner (GDP) social worker and social work authority (where appropriate) foster parents (where relevant) The describe their proposed facilities to provide this functionality. The Bidder shall describe their proposed facilities to provide this functionality.
121.6.2
121.7 121.7.1
The Service shall permit specification of the effective start and end dates for each relationship including dates in the future. Use of Existing Data The Service shall provide a facility to flag existing data about basic patient details and basic care relationships that are held in retained legacy systems or have been migrated to new applications.
FINAL 1.0a
Page 388 of 607
ICRS
Requirement The user shall be presented with a mechanism (e.g. checkboxes) to enable items to be flagged as valid and of good quality to be maintained on the Personal Spine Information Service. Section 975.3 contains related requirements.
Required Response
FINAL 1.0a
Page 389 of 607
ICRS
122 Emergency\Unscheduled Care including A&E and GP Out-of-Hours (and NHS Direct)
Unscheduled care management Purpose

To enable the management and recording of unscheduled care provided in any s etting including Accident and Emergency ( A&E), out of hours, primary care facilities (including practices), ambulances (e.g. where paramedics are able to treat patients themselves instead of taking them somewhere to be treated), walk in centres, minor injury units and NHS Direct. To incorporate attendance management, waiting time recording, and clinical intervention. In respect of patients for whom a decision is made to admit to hospital, to incorporate the identification and allocation of beds that are available for use, bed occupancy and the corresponding demand (link to 108 scheduling).
User Population
Clinical and non-clinical staff that are required to deliver or administer unscheduled care.
Care Setting
Hospital and clinic based care. Care provided through NHS Direct, in the patients home or in other care settings where unscheduled care is provided.
Patient/Client Access Requirements Patient access will not be required directly, however information on waiting times, number of users and other data required centrally about these services shall be made available to central information sources such as Strategic Health Authorities (SHAs) and the Department of Health (DOH). Systems integration. Shall share the Personal Demographics Service (PDS). Integration with resource scheduling and eBooking. Integration with all clinical components such as assessment and clinical noting to ensure clinical activity is linked to the visit/ attendance. Integration with results reporting. Data systems shall be able to provide, at a minimum, current central data requirements. Shall integrate with NHS Direct and ambulance call centre systems.
Benefits
Will enable more effective management of unscheduled care.
FINAL 1.0a
Page 390 of 607
ICRS
Will contribute to reducing waiting times in A&E as patient flows through the hospital can be managed more effectively and support timely discharge from A&E. Will enable more timely, appropriate and effective treatment interventions due to the incorporated information regarding to the patient background and record.
Composition
Identification of resources and facilities which can potentially meet the needs of the patient as part of delivering unscheduled care. Administration of unscheduled cases. Identification of available beds once a decision to admit a patient to a facility has been made. Booking of patient into a facility once a decision to admit a patient to a facility has been made, either through resource scheduling, ebooking or by another method. Results reporting. Recording and management of attendances and clinical activities including waiting times and patient tracking.
Exclusions
Scheduled care.
Functionality
Patient tracking and location. Management of attendances, including waiting times. This service shall link to ambulatory care management and bed management systems. This service shall link with assessment and clinical noting components to link attendance record with clinical record. Admission, transfer and discharge of patients. This service shall link with social care support systems to access combined care plans and the provision of joint social and health care services on discharge.
Assumptions
Scheduled care shall be delivered by other parts of this section. NHS Direct and out of hours facilities could be either separate or part of the ambulance callcentre system with an interface to unscheduled care functionally the physical location of these three components may vary and each option must be possible.
FINAL 1.0a
Page 391 of 607
ICRS
122.1 122.1.1
Unscheduled Care Management This Service shall be part of the fully integrated scheduling. The admitting and booking system shall link with: bed management; ambulatory care management; scheduling; results reporting; rostering; capacity monitoring and planning; and transport. Bidder to describe how they address these requirements. shall Bidder to describe how they address these requirements. shall
122.1.2
The Service shall have the ability to record all details of the care delivered including all staff involved, date and time, type of intervention, duration, etc. The service shall provide the facility to manage unscheduled care for patients in any setting. The service shall include the following elements: patient tracking and location; management of attendances, including waiting times; link to ambulatory care management and bed management systems; link with assessment and clinical noting components to link attendance record with clinical record; admission, transfer and discharge of patients; and link with social care support systems to access combined care plans and provision of joint social/health care services on discharge. Accident And Emergency The Service shall provide the facility to register patients on the PDS if required and generate an A&E attendance number which shall be a new number for each patient for each A&E visit. The Service shall provide a detailed history of care covering all previous A&E attendances and provide a total count of these on user definable screens. The Service shall provide facilities to support clinics for A&E.
122.1.3
Bidder to describe how they address these requirements.
shall
122.2 122.2.1
122.2.2
122.2.3
FINAL 1.0a
Page 392 of 607
ICRS
122.2.4
The Service shall have the facility to record hospital hoppers (i.e. persistent attenders to different A & E departments e.g. drug addicts and attention seekers). The Service shall alert the appropriate health care professional (HCP ) as soon as a patient contact with a hospital hopper is registered. The Service shall provide access to the bed management screen where GP referred patients are admitted through A&E and advanced notification of how many patients are due to arrive shall be shown on the A&E screens. The Service shall provide lists of expected A&E patients including a facility to receive pre-arrival information from mobile computer systems (e.g. ambulance data) including: times; drugs administered; readings taken; and pre-registration of the patient.
122.2.5
122.2.6
122.2.7
The Service shall comply with national standards in place from time to time for the triage (prioritising) of patients through the A&E department and reviews of these priorities as the numbers of patients waiting increases or over a period of time. The Service shall also allow streaming of patients in circumstances where a see and treat system is implemented. The solution prioritisation system required is currently the UK national standard triage system. A function shall be provided to automatically calculate the triage score as data is entered using decision support algorithms. These shall include: P1 Red P2 Orange P3 Yellow P4 Green P5 Blue P6 P9 Immediate. Very Urgent. Urgent. Standard. Non-Urgent. Dead. patient not
122.2.8
triaged.
122.2.9
The Service shall provide the facility for clinical staff to override allocated priorities according to
FINAL 1.0a
Page 393 of 607
ICRS
their own judgement. 122.2.10 The Service shall have the ability to record the precise location of the patient in the A&E Department and to display views of different parts of the A&E Department so that users can see the status of each patient in a location. The Service shall provide a facility to alert staff if patients have not been triaged or seen within specified configurable waiting times. Patients who are nearing a breach or have breached a waiting time rule shall be depicted clearly on the display screens described above (e.g. by highlighting in colour). The Service shall provide a facility to alert users when a presenting patient is in an 'at risk' category or may be a risk to staff. The Service shall provide a provisional discharge screen where patients records are placed when treatment is complete. Patients records can be taken from screen for final discharge or reactivation in the A&E department. The Service shall provide a facility to record a change in the on-take consultant while the patient waits to be seen. The Service shall alert clinical users immediately should the measurements obtained from monitoring equipment represent adverse clinical data (i.e. in circumstances where the measurements fall outside defined parameters). The Service shall have the ability to offer telephone triage facilities. This is particularly appropriate for eye injuries. In this instance, the triage date shall be recorded separately from the A&E attendance date. The Service shall record Minors/Majors flag to record the category of patient. The Service shall enable the retention of a patient dependency scoring system e.g. the Barthel index or any other accepted scoring system. The dependency score shall be measured at regular intervals during a patients attendance. Details of the Barthel scoring
122.2.11
122.2.12
122.2.13
122.2.14
122.2.15
122.2.16
122.2.17
122.2.18
FINAL 1.0a
Page 394 of 607
ICRS
system are available. 122.2.19 The Service shall support rule-based functionality to be utilised behind the various observations to assist with clinical practice. This shall provide embedded user definable guidelines and protocols to enable decision support which are invoked when certain presenting conditions are seen. The Service shall provide a facility to record accident data based on: 122.2.21 type of accident; type of environment in which accident took place (home/work/school etc.); location of accident; and date and time of accident.
122.2.20
The Service shall support the management of a library of advice leaflets and prompt the user to print the appropriate leaflet to give to the patient once a diagnosis has been established. Trusts require this information to come from their existing intranets and therefore linking to such intranets is required. The service shall provide the facility to code data, in real time, using defined codes. It shall be possible for these codes to be mapped to national codes.
122.2.22
FINAL 1.0a
Page 395 of 607
ICRS
122.2.23
The Service shall prompt the triage nurse to define the intervals at which the patient should be re-triaged whilst waiting for care and shall enter that requirement on her/his worklist. The Service shall provide the facility for patients presenting directly to an A&E Department to be seen initially either by a triage nurse or the registration clerk depending on local practice. This facility shall enable the opening of a new attendance record and shall date and time stamp the first patient encounter with a staff member. In the event that the triage nurse sees the patient first the minimum demographic data to establish the patients identity will be required. The Service shall record the patients triage score and start a waiting time count down depending on the triage category. It shall appropriately present both data and alarm at a locally definable time before the relevant waiting time limit is breached. The Service shall be capable of receiving an ambulance service generated electronic patient report form (ePRF) prior to the arrival of the patient in the A&E Department and shall merge such details into the new attendance record to include: demographic data; the case number and ambulance service triage category; a clinical history of the case so far including an anatomical representation of any injuries; key physiological monitoring data including temperature, pulse and respiratory rates, blood pressure (BP), blood oxygen concentration (PaO2), ECG and the results of near patient testing (e.g. Troponin I). Where appropriate these will be presented in graphical format over periods of time; digital photographs (e.g. the damaged vehicle following a road traffic accident (RTA)); and key performance indicators such as call
122.2.24
122.2.25
122.2.26
FINAL 1.0a
Page 396 of 607
ICRS
time and scene time. 122.2.27 The Service shall enable incoming patients to be identified by key demographic details and an indicator showing whether such patient details have been validated. The Service shall support the concept of an effective display of patient information. It shall include the following information as a minimum: a prioritised list of all patients combining the data from minors and majors including any patients who are awaiting handover from the ambulance service patient information shall include patient identification, triage category, waiting time, current location and status. a pictorial representation of the A&E Department including individual beds and trolley spaces link patients to individual beds and spaces link with patient tracking to show where each patient is (e.g. in X-ray) link with staff tracking (e.g. to show staff numbers per department) show w hich bays and beds are occupied, reserved or free current and anticipated workload incoming and expected arrivals emergency care network capacity giving summary information of surrounding departments and the ambulance service hospital capacity status including planned discharges capacity status of local tertiary referral centres staffing levels by clinical areaThe information should be presented in a manner that supports easy access and
122.2.28
FINAL 1.0a
Page 397 of 607
ICRS
rapid decision making by staff.
122.2.29
The Service shall support the direct allocation of a hospital bay to a inbound patient by ambulance control. The Service shall enable remote access by ambulance control to enable direct admission of patients. A&E Treatment The Service shall be capable of supporting the patient flow process and the delivery of treatment. All steps in the progress of a patient through the A&E Department shall be time and date stamped, for instance using bar code readers, along with physically tracking the patient within any given site.
122.2.30
122.3 122.3.1
FINAL 1.0a
Page 398 of 607
ICRS
122.3.2
As a minimum the following timed events shall be recordable, with spare fields that can be defined in the future: arrival in A&E and triage; registration; re-triage; patient seen by healthcare professional; x-ray request; patient sent to x-ray; x-ray performed; patient back from x-ray; patient referral to specialty; patient seen by specialty; decision to admit patient; treatment of patient concluded; and leaves A&E Department.
122.3.3
The Service shall provide a facility to inform other HCPs of discharge (electronically and in paper format) and the outcome of attendance (e.g. admitted as an in-patient, sent home etc.) in real time. As a minimum, a discharge letter shall be generated automatically from information acquired as the patient flows through the system but this discharge letter shall also permit free text input. The Service shall provide a facility to record and display the transfer of responsibility for treatment of patients in an A&E Department to non-A&E doctors. It shall also be possible to record and display the duty consultant of the day. The Service shall provide a facility to show waiting information (times and case types) and graphically show patient priorities based on allocated triage codes and time elapsed since
122.3.4
122.3.5
FINAL 1.0a
Page 399 of 607
ICRS
triage. 122.3.6 The Service shall alert designated staff if a patient leaves the A&E Department using the patient tag. The patient tag will alert staff if confused patients wander or if patients chose to leave before treatment is complete. The Service shall enable patients in the A&E Department to be scheduled for investigation or specific treatment (e.g. X-ray) . The Service shall provide an alert if the patient is not moved towards the required location a t the designated time. 122.3.8 The Service shall identify all outstanding investigations and indicate the status of the result. When a result becomes available this will be notified to the requester. The Service shall record the fact that a patient has refused further treatment and where these circumstances arise, an electronic signature from the patient shall be required by the Service and supported. The Service shall enable an inventory of the patients belongings to be registered and signed for electronically by the patient and staff. The Service shall support remote authorisation of a procedure (e.g. it can record in an auditable way that a consultant in an A&E Department has authorised a nurse in the Minor Injuries Unit to suture a particular wound Children in A&E It is assumed that an electronic copy of Child Protection Register (CPR) data will be available in some form. The service shall be able to set up real time links to CPR data to enable a suitable check to be made. This shall include a prompt to the triage nurse on all under-16 year olds admitted to the A&E Department. The Service shall provide functionality to support treatment and care planning in accordance with emerging local and national guidelines and standards (e.g., the document, "Getting the Right Start" (available at the URL,
122.3.7
122.3.9
122.3.10
122.3.11
122.4 122.4.1
122.4.2
FINAL 1.0a
Page 400 of 607
ICRS
<http://www.doh.gov.uk/nsf/children/hospitalsta ndard.pdf>) details guidelines regarding the discharge of children about whom there are possible child protection or other concerns). 122.4.3 The Service shall support the checking of any child attending A&E under the age of 16 years old against the CPR with the facility to view the details recorded on the CPR. When recording an A&E attendance for children between the ages of 5 and 16 years old, the Service shall automatically prompt the user to record the name of the child's school. When recording an A&E attendance for preschool children the Service shall automatically prompt the user to record the name of the childs health visitor. Road Traffic Accidents (RTAs) The Service shall provide a facility to record the following information from patients in RTAs and support the collection of income from the compensation recovery unit: patient name; patient attendance number; road traffic accident (yes/no); seat belt fitted (yes/no); seat belt worn (yes/no); drivers name; drivers address; drivers postcode; accident location (with free text); accident date; accident time; airbag fitted (yes/no); and airbag deployed (yes/no).
122.4.4
122.4.5
122.5 122.5.1
FINAL 1.0a
Page 401 of 607
ICRS
122.6 122.6.1
Major Incidents The Service shall provide the facility for users to invoke Major Incident functions to highlight patients involved and produce police lists etc. The Service shall support all enquiries and the originators of the enquiries to be logged. The Service shall automatically generate user definable major incident identifiers for each patient (or a group of patients) on an anonymous basis. These identifiers shall then be matched retrospectively to real patients using patient details. On declaring a Major Incident, the Service shall automatically alert and include the major incident plan on all access points to ICRS in the A&E Department and relevant parts of the health community. On declaring a Major Incident, the Service shall automatically support the call in of on call staff in line with local procedures The Service shall be capable of being rapidly expanded into pre-determined overflow locations (e.g. a physiotherapy department). The expansion will include an increase in the number of triage and treatment stations. Out of Hours Support Appropriately authorised access shall be provided to all relevant services, such as but not limited to the Spine and full ICRS records from all primary care locations. Remote secure access, such as but not limited to PSTN and GPRS, shall be provided for mobile members of PHCT or for clinicians on home visits as appropriate and practicable. The practicality of such access shall be subject to review as new technologies become available and more cost-effective.
122.6.2
122.6.3
122.6.4
122.6.5
122.6.
122.7 122.7.1
122.7.2
FINAL 1.0a
Page 402 of 607
ICRS
123 - eHealth and Clinical Development Overview ICRS is a key enabler for implementation of "The NHS Plan: A Plan for Investment. A Plan for Reform" published in 2000 (NHS Plan), the wider modernisation agenda, implementing all the National Service Framework standards, as well as overcoming the health deficits of social disadvantage. It will be the critical foundation for provision of integrated patient centric care. In so doing it has a key role to play in supporting and enabling clinical development and service developments generally. Most of the diagnostic and therapeutic tools available are becoming more accessible for community clinicians and patients to use directly. These devices are deployed currently within the community but lack the integration with electronic records to gain the real benefits from home and community based deployment. Currently the networking and remote support is lacking which will enable virtual supervision by specialists to become the norm rather than the exception. ICRS will provide the critical component to enable home and community based developments to be fully deployed. Community intermediate care facilities (community hospitals, DTCs primary care centres etc.), will become the hub for work that was previously dependent on the secondary care sector with whole specialities (e.g. dermatology) and DRGs (e.g. congestive heart failure) being managed wholly within the community. Self monitoring and do it yourself diagnostic kits bring a new level of citizen-patient empowerment and care not previously possible even within the hospital setting. Importantly, many of these concepts are generic (e.g. measurement of autonomic function such as heart rate variability (HRV) across the major diseases (e.g. CHD, Diabetes)) as well as being valuable measures of stress and risk factor detection. The extension of ICRS to the patient at home or on the road opens up the opportunity of self- measurement on a community-wide scale. The inequalities of health services, especially for those disadvantaged, can be tackled by appropriate use of ICT. 40% of UK citizens are considered to be at some social disadvantage inner city areas are greatly in excess of that figure with clear evidence of the increased burden of ill-health and disease. Experience with citizen developed electronic records and websites indicates that these serious inequalities of health and social care can be overcome. There are plans in the Governments health policy to introduce contracts between patients and the NHS to engage in lifestyle changes where the health of the patient is obviously compromised by smoking or bad diet, but these will fail without active support programmes. The ICRS and myhealthspace websites shall be a key portal to deliver and monitor this and provide the eHealth tools to self manage care. These are the same tools supporting intermediate care services to optimise diagnosis and management of established diseases. The advent of new therapies, such as gene therapies, lie beyond these relatively simple clinical innovations, but will emerge within the ICRS implementation time frame. New evidence shows that 24-hour personal monitoring will enable the customisation of gene therapies such as those controlling circadian cardiovascular function which is important in vascular conditions such as MI and stroke. Clinical audit and research is crucial to the improvement of performance and advancement of the evidence base and must be supported by ICRS. A huge potential for a world leading anonymised database for academic, epidemiological and pharmacological research over the whole care pathway can be created through the ICRS. Subsets for population based research, disease specific research, adverse events and therapeutic side effects studies become feasible through a well designed ICRS.
FINAL 1.0a
Page 403 of 607
ICRS
eHealth ICRS integrated within other eHealth technologies will be a key supporting technology for the New NHS - an NHS where the citizen/patient is fully empowered to ensure their optimum health wherever they are, assisted seamlessly by their health professionals. Patients will be better informed about their illness, their general health and well-being and about the services that are available to them. ICRS and eHealth will support this by: interactive patient/public websites Accessible by the Internet and digital TV (to reach the 40% of the UK population outside the digital divide). Supporting broad patient/citizen participation. Enabling patients to make informed decisions about their own health (patient education and support). Support choice (direct access to booking options). Tailored to meet their individual needs.
interactive community health professional training and education.
Consequently the population as a whole will take more ownership and personal responsibility for their own health which in turn will support greater emphasis on disease/illness prevention and health promotion rather than sickness and cure. Wider access will mean that even more care will be delivered in the local community and patients' homes, leaving secondary and tertiary care centres to deal with selected acute and complex conditions. Wireless personal telemetry (intelligent garments and implantable nano sensors) and near patient testing (including portable scanners) will be deployed with critical links to a function rich ICRS. The expertise and skills of a wider range of clinicians will be used to deliver healthcare and there will be much more emphasis on team working with technology supporting community Clinicians and projecting specialist expertise to the patient via telemedicine. Supporting major changes in patient management using virtual education and training will be important. Many of the benefits of an eHealth enabled ICRS have been described above. The evolution is appropriately described in tiers of generic functionality. Tier 1 addresses the urgent need to meet the disease related standards of the NSFs with a shift to community based care and early involvement of the patient in their care. Tier 2 addresses the involvement of citizens in supported health promotion and new levels of customised diagnosis, monitoring and therapy enabled by a function-rich ICRS. Tier 3 allows for new evidence based diagnoses and therapies to emerge, especially those from ICRS implementation and gene therapy and pharmacogenetics and likely to occur within the full implementation period of the ICRS. Integration of eHealth functionality within phase 2 of the ICRS means that generic health promotion and risk prevention in the population as well as diagnosis and management of chronic diseases in the community (including MDTs), especially for early adopters, will be supported.
FINAL 1.0a
Page 404 of 607
ICRS
Patient-centred care: ICRS e-volution: Integrated Implementation Strategy

Value to the patient
Spine e-booking e-prescribing Choice of Access to professional services
Medical & social information & education E-monitoring 2 Separate clinical/ 1 Audit and audit databases demographic databases
Passive interactive
ambulatory & home therapy
Early use of ehealth

Patient ICRS
on-line care
ICRS NHS Direct
phase 1 healthspace 1
phase 2 healthspace 2
The diagram emphasises the need for integration of e-health within the ICRS functionality to deliver NSF targets and the opportunities of clinical innovation. Critically, this ICRS strategy also provides for flexibility across healthcare communities, enabling innovative and progressive communities to make progress, possibly as demonstrators to inform full national roll-out of the ICRS. The specific eHealth components which are described in more detail below include: home-based and ambulatory patient monitoring; virtual visiting; video conferencing; and store and forward referral.
Components Home based and Ambulatory Patient Monitoring This facility supports the recording o a patients daily activity and records physiological f observations (intermittent) and measurements (continuous), increasingly wireless, at home or while mobile, to support diagnosis, risk assessment, treatment titration, surveillance and management, through links to monitoring equipment. Links to environmental monitoring will also be included. For some patients (e.g. those with dementia, confusion, or at risk for falls) the establishment of the normal behaviour pattern is needed and this can be expected to become more widespread as it is used in other conditions The development of near patient testing means that the system should be adaptable to accept input from testing devices. These systems are generic with those used by citizens adopting health life style and risk prevention programmes. Virtual visiting
FINAL 1.0a
Page 405 of 607
ICRS
There is a requirement for staff across all care settings to be able to virtually visit patients in their own homes or any intermediate care facilities in the community. To date this has been achieved by the use of video phones or set top boxes using the domestic television. This will enable the much more efficient use of specialist community staff who will be able to use virtual visiting to provide greater continuity of care at reduced cost, prioritise the actual visiting to those in greatest need, provide support and in some cases psychological treatment and supervise a patient or their carer in self or care treatments. Video Conferencing Consultations by video between GPs and specialists in hospital and community centres already form part of the pattern of service and such use will increase significantly. The majority of the meetings will be within the NHS but facilities need to be available to achieve connectivity across the public ISDN network to other private institutions and abroad. As well as these more routine applications, there will be increasing use of similar consultations in urgent and emergency situations. For example, minor injuries units linking to A&E Departments and A&E Departments to specialist burns, neurology, chest and spinal units. Specialist childrens services, including maternity, already recognise this need. Store and Forward referral Increasingly e-consultation will replace some out-patient attendances. The majority of these will consist of formatted patient history with the attachment of images and other diagnostic findings which will be forwarded for specialist opinion and advice. The normal routing will be from primary to secondary care but there will also be primary to primary referrals, secondary to tertiary referrals and secondary to secondary referrals. This service will enable a referring clinician to send a patient history together with test results and images to another clinician for expert advice on diagnosis, treatment and management. Benefits & Outcomes Current situation Some electronic support for patients is available but is limited in scope Desired benefits & Outcomes Patient provide reassurance for patients and carers; improved quality of life for patients; increase patient control of their activities and treatment; support effective intermediate care; reduce patient travel times and costs; and bring urgent help to patients who fall or collapse and enable prompt treatment.
FINAL 1.0a
Page 406 of 607
ICRS
Clinician provide reassurance for professionals; support research and new evidence base; enable more accurately focused healthcare; enable cancer networks to meet planned targets for MDTs and mental health best practice for Care Programme Approach for Mental Health (CPA) meetings; better care planning and improved care pathways especially in tertiary specialties; optimise use of clinician time; mechanism to support improving skills of the referrers; and provide highest quality individualised data.
Manager enable earlier patient discharges and prevent some admission for risk and exacerbations of chronic conditions and admissions; maximise input from scarce specialist staff.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Home based and Ambulatory Patient Monitoring available in 10% of the NHS to support the development of innovative and demonstrator projects. Virtual visiting available as required to primary, secondary and tertiary care centres. Video conferencing available as required to primary, secondary and tertiary care centres. Store and forward referral - available as required to primary, secondary and tertiary care centres.
Minimum Level to Be Achieved by December 2006 (Phase 2) Home based and Ambulatory Patient Monitoring available in 50% of the NHS to support the development of innovative and demonstrator projects. Virtual visiting available to 10% of primary, secondary and tertiary care centres. Video conferencing available to 10% of primary, secondary and tertiary care centres. Store and forward referral - available to 10% of primary, secondary and tertiary care centres.
FINAL 1.0a
Page 407 of 607
ICRS
Target for 2010 Home based and Ambulatory Patient Monitoring available in 90% of the NHS to support the development of innovative and demonstrator projects. Virtual visiting available to 50% of primary, secondary and tertiary care centres. Video conferencing available to 50% of primary, secondary and tertiary care centres. Store and Forward referral - available to 50% of primary, secondary and tertiary care centres.
Requirement 123.1 Home based Monitoring and Ambulatory Patient
Required response
123.1.1
The Service shall enable the recording and monitoring of a patients daily activity and record physiological observations and measurements at home or while mobile to support diagnosis, risk assessment and treatment titration. This monitoring programme, suited to each particular patients needs, shall be established and limits defined. The establishment of the normal behaviour pattern for some patients is required
123.1.2
The Service shall link with: community alarm systems; movement, pressure, sensing devices; physiological devices; (& contact and falls
environmental)
sensing
24-hour call centres, alarm systems and specialist advice including, in the future, NHS Direct; ambulatory management; and domiciliary care
123.1.2
risk assessment and risk management; near patient testing devices. Each bidder shall describe how this will be
The Service shall be able to recognise:
FINAL 1.0a
Page 408 of 607
ICRS
data falling outside externally or internally generated parameters and transmit an alert or alarm call locally and remotely when this occurs; and erroneous data and transmit an alert or alarm call locally and remotely when such data is transmitted or inputted.
achieved.
123.2 123.2.1
Virtual visiting The Service shall support virtual visiting (i.e. enable clinicians to provide domiciliary and intermediate care to patients in their own homes by electronic means). Such virtual visits shall be capable of being scheduled and shall be recorded as an activity within the patients care plan. The Service shall integrate with all ICRS components and physiological and daily living monitoring systems and be appropriately controlled by the applicable confidentiality constraints. The Service shall enable records, including images, results and care pathways, to be viewed simultaneously with the video image as part of a virtual visit. Video conferencing The Service shall facilitate case conferences, MDTs, CPA meetings, remote consultations, teaching sessions by means of video and audio conferencing between clinicians located in a range of care settings such as NHS Direct, walk in centres, Primary Care, Acute, Mental Health, Ambulance, patients home. Such conferencing shall be capable of being scheduled and shall be recorded as an activity within the patients care plan. Each bidder shall describe how this will be achieved. Each bidder shall describe how this will be achieved.
123.2.2
123.2.3
123.3 123.3.1
123.3.2
As well as cameras the Service shall accept input from computer systems, PACS, pathology and any other digital image sources. The Service shall support: multiple and split screen displays for the placing of service requests either individually or as commonly requested sets; run over IP and have access to open ISDN
FINAL 1.0a
Page 409 of 607
ICRS
systems; 123.3.3 be supported by automatic bridging capability for multi user conferences; and integration with voice systems to allow voice only links.
The Service shall enable: records, including images, results and care pathways, to be shared as part of a video conference or consultation; and participation in video conferences and consultations to be recorded as a defined activity which can be aggregated and analysed.
123.4 123.4.1
Store and Forward referral The Service shall provide a way of presenting patient information, including relevant images and results, and attaching these to a referral request for a remote consultation. The service shall provide a set of configurable structured templates. The service shall integrate with ICRS functionality, eBooking, PACS, Pathology and other imaging and test management systems. The service shall ensure that asynchronous clinical activities are efficiently co-ordinated. The Service shall ensure the collection of serial data so that patterns of physiological and behavioural activity (e.g. cardiorespiratory sleep disturbances and fetal heart rate patterns) can be recorded, processed, examined locally and transmitted for remote consultation when required. Each bidder shall describe how this will be achieved.
123.4.2
Each bidder shall describe how this will be achieved. Each bidder shall describe how this will be achieved.
123.4.3
123.4.4
Each bidder shall describe how this will be achieved. Each bidder shall describe how this will be achieved.
123.4.5
FINAL 1.0a
Page 410 of 607
ICRS
124 Information to support secondary analysis and reporting Overview This module outlines the requirement for the service to support the abstraction, reporting and analysis of information on the care provided to specific groups or classes of patients. This information is required to support a range of secondary purposes, including: the management of operational services; quality monitoring and clinical governance; service performance improvement and accountability; service planning and commissioning; performance management and accountability, including the production of mandatory returns or information extracts by local NHS organisations and their commissioning and service provider partners; disease surveillance; and research.
Although these business activities require access to and the analysis of data abstracted or derived from individual patient or Patient Records, they are not directly concerned with the care of an individual patient. Scope These activities may be categorised as in Figure 1 below. This indicates that direct care activities and the management of operational services should entirely be supported through the implementation of consistent Integrated Care Record Services, including NASP solutions within local care communities.
Secondary Analysis and Reporting

Operational / Direct Care Tactical Audit / Performance review Strategic / Planning
Examples of characteristics of requirements

Identifiable records for Individual persons Immediate access Dynamic, up to date Frequent abstracts
Focus on classes of persons Time series Short time intervals Prospective indicators Focus on classes of patients Actual compared with expected (inputs, outcomes) Ongoing Indicators
Focus on classes of patients Service and population based Forecasting Periodic
ICRS
LPRAS / NPRAS
FINAL 1.0a
Page 411 of 607
ICRS
Figure 1 : Scope of Secondary Analysis and Reporting Service Reporting requirements associated with the management of operational services, such as those covering team and individual care professional caseloads and allocations are outlined elsewhere in this requirement. Other non-direct care activities will be supported through a combination of Local Patient Record Analysis Services (LPRAS) and the National Patient Records Analysis Service. The scope includes the following components: data abstraction; data management; reporting; analytical tools; and analysis services.
It should be assumed that every item of clinical data entered into operational systems shall be required to support a current or future requirement for clinical information. The only possible exception would be where this is an explicit breach of patient confidentiality. The scope also includes all requirements for management and executive information. These components are required to support both the analysis and reporting associated with clinical governance, surveillance and research activities and will support local and national service performance, improvement, management and accountability activities. This will include but is not limited to, current and future requirements for information to: deliver returns to the Department of Health, the NHS Executive, Local Authorities, and other organisations; provide summary information for commissioners and health authorities; provide a wide variety of data for audits and inspections; support timely delivery of the annual planning cycle; provide local managers and executives with information on the performance and effectiveness of business systems and processes; aid decision making at all levels; support service redesign and modernisation; and aid the interpretation of clinical information provided (see above).
It should be assumed that every item of data entered into operational systems shall be required to support a current or future requirement for management and executive information. The only possible exception would be where this is an explicit breach of patient confidentiality. Exclusions National Patient Records Analysis Services are not covered by this requirement. Benefits and Outcomes Currently data is provided from many NHS and Social Care Service organisations from a range of systems, both on-line operational systems and back office databases, and by direct data entry. This ad-hoc provision has an impact on the quantity, quality and timeliness of information provided.
FINAL 1.0a
Page 412 of 607
ICRS
The vision is to provide information for secondary purposes support as a by product of that required to support direct patient care. This information will be available in and across many administrative and clinical boundaries to ensure that the review of whole systems and processes can be achieved. Thus the benefits will include, but are not limited to: clinical, management and exec utive information shall be available immediately; routine reports, returns and analyses shall be available without manual intervention to aggregate or filter data; data quality will improve as data will be entered once only; information will be available to a consistent standard in and across organisations and care pathways allowing for effective comparisons to be drawn; a range of easy to use tools will be made available to allow wider access to information by clinicians, managers and staff, releasing highly skilled information analysts for more complex tasks; and data will be held in such a way that manipulation and extraction will not impact on the performance of operational patient care systems.
Dependencies Dependencies for this function include, but are not limited to: the development of effective links between local (and legacy) systems and local ICRS to ensure that all data required is immediately accessible; data within the systems above is to a consistent and high standard; availability of national and local information, particularly urgent changes to structures, content and timetables; and a high level of tailoring to meet the local requirements of organisations and clinical disciplines.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) By December 2004, the service shall be able to meet all requirements at that time for mandatory and statutory returns from the systems they have implemented. The service shall also be able to provide facilities for the local abstraction, management and reporting of information. In addition, by December 2004 the service shall include facilities for users to access information through easy to use analysis and reporting tools. Minimum Level to Be Achieved by December 2006 (Phase 2) By December 2006 the service will be developed and extended to meet all requirements at that time for mandatory and statutory returns from any patient care system within the LSP boundary. This additional range of data will also be available to satisfy local r eporting requirements and for direct access by users through simple to use analysis and reporting tools. In addition, by December 2006 the service shall include interfaces to corporate systems to help populate information analyses and reports, and ad-hoc queries. The supplier should also have trained a significant proportion of staff employed within the cluster in the use of the analysis and reporting tools provided.
FINAL 1.0a
Page 413 of 607
ICRS
Target for 2010 By 2010 the services shall be able to provide all current and future analysis and reporting requirements. The majority of NHS staff employed within the cluster will be trained in the use of, and be able to access, easy to use analysis and reporting tools. Requirements Requirement 124.1 124.1.1 Data selection, provision abstraction and Each bidder shall describe how this will be achieved. Required response
The service shall support the selection of Patient Records to be included in data abstracts, using ad hoc or standard selection criteria. Criteria may be based on for example: the personal characteristics of the patient (age, sex etc.); their area of residence or the Primary Care Trust / practice with which they are registered for GMS/PMS; provider organisations involved in their current and planned care; care teams or care professionals involved in this care; the condition or problem for which investigations, assessments and care is being provided; the occurrence of particular activities in a spell of care; elapse times between activities in a sequence of care or care spell; the settings and locations in which care is provi ded; and the types of resources used to provide care etc.
124.1.2
The service shall support abstraction of data from these records, such that: the abstraction of data may be on either a regular or an ad-hoc basis; regular abstracts may be required to be produced for different intervals (several times a day, daily, weekly, monthly etc.) depending on the purpose for which secondary analysis is required; all data within Patient Records shall be capable of being selected for abstraction; and standard subsets of data for abstraction may be defined for regular abstracts. For other purposes ad hoc selection of
FINAL 1.0a
Page 414 of 607
ICRS
Requirement subsets should be supported. 124.1.3 The service shall support abstraction processes, which require: the anonymisation or pseudonymisation of data relating to individual patients. All person related information used to support non-direct care activities, shall be effectively anonymised. See section 730 Information Governance; data relating to all activities associated with the pathway of care for an individual patient; or data relating to individual activities or groups of activities, which comprise specific components of this pathway; derivation of new data, through transformation, arithmetic processing of or the application of classification rules; examples include the truncation of postcodes to ensure effective anonymity, the calculation of elapse times between activities and the classification of individual care activities or combinations of care activities into Healthcare Resource Groups; and aggregation of person level data.
Required response
124.1.4
The service shall support the provision of the abstracted data to Local Patient Record Analysis Services or National Patient Records Analysis Services. This will include abstraction of data from contemporary or legacy systems. The service shall support the extraction and submission of nationally-agreed datasets for submission to the NHS Wide Clearing Service. The service shall support the extraction and submission of nationally-agreed datasets for submissions to the National Clinical Audit Support Programme. The data abstraction tools and services shall support both abstracts of data from ICRS and NASP solutions (PDS,
124.1.5
124.1.6
124.1.7
FINAL 1.0a
Page 415 of 607
ICRS
Requirement Spine, E-booking) relating to the care of individual patients and abstracts from a range of other business applications including those supporting the operational management of financial and human resources. Such services shall also enable LPRAS to maintain comparative or benchmark information abstracted from NPRAS. 124.1.8 The service shall support the production of statutory social care returns for NHS patients (it is not expected that the service shall handle persons treated wholly within Social Services). This will include, but not be limited to, the following adult client categories: older people; mental health; persons with physical disabilities; persons with learning disabilities; persons suffering from substance use; and other vulnerable adults, where their social care has been recorded on the systems.
Required response
In particular RAP, PSSEX1, SSDA702, SSDA902, HH1, SR1). A brief description of adult returns can be found at www.doh.gov.uk/public/oct02appendix1 .pdf and full return descriptions for rap can be found at www.doh.gov.uk/rap/ 124.1.9 Where information is held as free-text, the service shall be able to deploy freetext indexing and searching facilities (over both the free-text and data items) Data Management The service shall provide facilities for the update of individual data records. Data management services shall ensure both the integrity of data and timeliness of data managed, applying updates and amendments initiated by data providers. The rules and processes for abstracting data may Bidders are asked to state how they could supply free-text indexing and searching facilities over selected sub-sets of service users and their records.
124.2 124.2.1
FINAL 1.0a
Page 416 of 607
ICRS
Requirement differ across the data types to be managed. 124.2.2 The service shall provide facilities for the derivation of new data items, where this is not a component of the abstraction process. These are data that are produced by calculations based on data within the abstracted records, for example duration of activities (lengths of stay). The service shall provide facilities for the classification of records within patient level abstracts, where classifications have not been applied during abstraction. There may be, for example by: type of activity; procedure or condition groups; or linkage of patient level records, where abstracts cover fragments (discrete activities) within an overall care pathway or continuum.
Required response
124.2.3
124.2.4
The service shall provide facilities for the aggregation of data into patient classes. The service shall provide facilities for the linkage of aggregate data relating to patient classes to enable construction of indicators. The service shall provide facilities for data validation and error / quality notification (including reporting the quality status of data to both data providers and patients). The service shall provide facilities for the production of subsequent data extracts, which may be supplied to users in a range of structures and media. These will include: routine extracts and clearing of data; and user defined extracts through rules based electronic interfaces, which may be self extracted or supplier provided.
124.2.5
124.2.6
124.2.7
FINAL 1.0a
Page 417 of 607
ICRS
Requirement 124.3 124.3.1 124.3.2 Reporting The service shall support the production of pre-defined tabulations and reports. The service shall provide pre-defined report templates and graphical formats, which may be used to present / analyse user selected data. The service shall support the production of standard aggregate tabulations or counts from patient level data to: 124.3.4 meet NHS wide requirements; and/or support user requirements. mandatory business
Required response
124.3.3
The service shall support the construction and presentation of indicators. Indicators may be of absolute performance or outcomes, (e.g. rate per 1000 patients re-admitted as emergencies within x days of discharge) or comparative (e.g. actual readmissions / expected re-admissions given rates for a peer group of similar care communities).
124.3.5
The service shall support the provision of standard report templates and structures, including graphical formats for presentation of user defined analyses / tabulations. The service shall support the extraction of tabulations and analyses, produced as data / contribution files. Analytical Tools The service shall include the provision of services and software tools, which support the receipt of data abstracts and their subsequent management, where required. The service shall include tools support the routine analysis of data. to
124.3.6
124.4 124.4.1
124.4.2 124.4.3
The service shall provide the tools to enable the local development of forecasting models of service demand, capacity and financial commitments.
FINAL 1.0a
Page 418 of 607
ICRS
Requirement 124.4.4 The service shall contain geographical or accessibility analysis tools, including models to enable the impact of location decisions to be evaluated. The service shall include tools to support the more complex analysis of data. The service shall provide the statistical and other analysis tools to support user defined analysis. Support for Local Patient Records Analysis Services
Required response
124.4.5
124.4.6
124.5
The contractor may be required to provide support for Local Patient Records Analysis services. This support may comprise a combination of different components. Numbers and proportions of patients discharged from hospital with different problems, receiving intensive rehabilitation support and the effectiveness of this support in: Preventing re-admission Achieving intended Outcome achievement rates for patients receiving different types of treatment by care professional / team.
124.5.1
The service shall support the production of outputs for quality and clinical governance, with analysis by: Clinical and care networks, and care communities; Individual care services providers; and Clinical and care teams, within organisations.
Numbers and rates of patients with complications and unplanned and adverse outcomes following care or treatment. 124.5.2 The service shall support the production of outputs for service planning, including assessment of health and care needs. Analysis shall be provided by: SHAs or clusters of PCTs and NHS Trusts e.g. to support service reviews, capacity planning etc; and to support the development and implementation of clinical networks. Local care communities e.g. Strategic Partnership Level with Local Authorities to support local whole systems delivery plans, including multi agency capacity planning. Access rates for different services, standardised for age and those characteristics of populations, which influence service demand. The prevalence or incidence of specific conditions or problems with populations. Comparisons of access rates prevalence between populations. and
FINAL 1.0a
Page 419 of 607
ICRS
Requirement 124.5.3 The service shall support the production of outputs for service performance improvement, monitoring and review. Analysis shall be provided by: Strategic Health Authorities, PCTs and NHS Trusts Appendix I to monitor and review the achievement of national and local objectives for improvement, access, effectiveness, outcomes, efficiency and quality. Appendix II Local Authority Health Scrutiny Committees Appendix III to monitor and review the effectiveness, outcomes, efficiency and quality of local health services. Appendix IV Clinical networks, local care communities and individual organisations Appendix V to monitor and review the achievement of national and local objectives for improvement, access, effectiveness, outcomes, efficiency and quality; and Appendix VI to enable the development of responses / plans to address performance issues. 124.5.4 The service shall support the production of outputs for commissioning. For Primary Care Trusts, individually and within collaborative commissioning models (with other PCTs) or in joint models with Local Authorities etc. to support the development and monitoring of service agreements, linked to Local Delivery Plans and health improvement plans, and funding arrangements through revised financial flows.
Required response Indicators of service outcomes, quality and efficiency, including for example: coverage of screening and prevention programmes, and numbers / rates of patients presenting for conditions covered by these programmes; rates of post operative deaths and complications; comparative elapse times stages in care pathways; between
rates and numbers of cancellations of booked activities; comparative distributions; lengths of stay
proportions of patients with delayed discharges; numbers and rates admissions etc.; of avoidable
indicators of performance that form the basis of the CHAI star ratings programme.
Prospective analysis of the impact of changes in the rates and volumes of referrals with different suspected conditions / problems on requirements for intermediate care, outpatient, assessment and investigative and inpatient (day case) capacity; and financial commitments against budgeted expenditure.
124.5.5
The service shall support the production
Access
rates
for
different
services,
FINAL 1.0a
Page 420 of 607
ICRS
Requirement of outputs for resource allocation. The analysis shall be by lcal NHS Organisations, in particular Primary Care Trusts, and across services within care communities. 124.5.6 The service shall support the production of outputs for research across local care communities and clinical networks (for example cancer networks) displaying medical (into for example the outcomes of particular treatment regimes). The service shall support the production of outputs for health surveillance showing, by local health communities incidence and prevalence of conditions / problems/treatments; identification of systematic service problems; and possible quality and
Required response standardised for age and characteristics of populations, influence service demand. those which
The prevalence or incidence of specific conditions or problems with populations. Analysis of geographical concentrations of the incidence and prevalence of specific conditions. Analysis of the rates of complications following specific treatments or of the duration of survival; non reoccurrence etc. Comparative rates of incidence and prevalence of conditions, and analysis of changes over time.
124.5.7
trends in treatments disease management.
125 Surgical Interventions.
Overview
Requirement 125.1 125.1.1 Theatres The ICRS Theatres module shall support all patient administration, information collection/reporting and scheduling functions associated with an NHS Trust operating one or more Theatre/Critical Care locations and specialty types. The Theatre Module shall be able to be integrated with other components of the EPR including the Enterprise Wide scheduling, requesting and results reporting. The service shall provide support for scheduled, emergency, out of hours and private patient
Required Response
125.1.2
125.1.3
FINAL 1.0a
Page 421 of 607
ICRS
Requirement services delivered within theatres. 125.1.4 The service shall provide the ability to develop individual patient protocols for emergency patients. This will include the ability to assign objects to the patient e.g. patient needs an ECG, and date and time stamping the point at which the object is assigned and removed. It shall be possible to group the objects. Sessions which are designated as emergency sessions shall be exempt from the normal delay and late finish audit procedures. The service shall allow regular reviews of emergency patients so that progress to surgery can be monitored and the outcome recorded. The service shall also provide for forced reviews of patients at user defined intervals. The service shall enable patient status to be recorded e.g. patient postponed until tomorrow. The service shall control scheduling of patients based on their status. Where it is decided to schedule a patient who does not have a status of ready, authority for the decision and the reason for it shall be recorded. The service shall produce an auditable log of the patient progress between booking and surgery. Scheduling Theatre Sessions The service shall support the creation and modification of a separate operational plan for each theatre. The operational plan shall be viewed as a calendar showing each planned theatre session. This shall take into account bank holidays and theatre maintenance days. The service shall group individual theatre plans together to create a combined schedule for a theatre suite. The service shall restrict access to operational plans whilst they are in draft form. Each theatre session record shall represent a block of time in the calendar of a theatre allocated to a
Required Response
125.1.5
125.1.6
125.1.7
125.1.8
125.1.9
125.1.10
125.2 125.2.1
125.2.2
125.2.3
125.2.4
FINAL 1.0a
Page 422 of 607
ICRS
Requirement particular consultant surgeon. The service shall enable the creation, amendment and discontinuation of theatre session records. 125.2.5 Creation of each session shall be associated with a specific theatre, a consultant in charge of session, operating surgeon if different and consultant anaesthetist. The service shall place individual sessions on the operational plan and indicate the session date and theatre location. The service shall move all or part of a session between theatre locations to reflect the actual use of theatre resources. The service shall assign one or more theatre cases to a session. The service shall record unplanned sessions and their associated theatre cases. The service shall record the cancellation of a planned session and indicate the reason for cancellation (preferably from a pre defined drop down list). The service shall permit the creation and modification of rolling plans showing the expected sessions for each theatre in a theatre suite, to include estimated anaesthetic time. The service shall generate a draft operational plan automatically for any given calendar period based on the rolling plan and the resource diaries. These plans shall be available for manual modification before they are published. Lists of cases for operations shall be automatically validated for obvious errors, e.g. wrong speciality of surgeon, not enough theatre time etc. List changes shall only be allowed by authorised personnel and be recorded with reasons. The service shall divide the theatre day into a number of definable sessions with predefined breaks. The service shall indicate if there is a break in the
Required Response
125.2.6
125.2.7
125.2.8
125.2.9
125.2.10
125.2.11
125.2.12
125.2.13
125.2.14
125.2.15
FINAL 1.0a
Page 423 of 607
ICRS
Requirement session and the length of the break. 125.2.16 The service shall record planned activity separately from actual activity, for the purposes of utilisation analysis. The service shall allow for the setting up of ad-hoc or special sessions easily. The service shall record the anaesthetist who normally attends and details of additional staff by type. The service shall set up records of theatre sessions to include: 125.2.20 theatre session code; theatre name; theatre location; consultant in charge; speciality; and anaesthetist, frequency, (daily, weekly, monthly etc.).
Required Response
125.2.17
125.2.18
125.2.19
The service shall provide specific theatre location default times for start and end of session. Theatre List - Creating Case Details The service shall create a case on the theatre list for any patient not on the waiting list but with an NHS number or system generated unique patient identifier (if the NHS Number is not available). The service shall create a draft theatre list with facility for a user to Add/Delete/Amend case details. The service shall create a draft theatre list as read only, clearly indicating its version status as a draft and preventing it from being printed/distributed while in draft format. The service shall permit a user to amend the order of the list and confirm a change of version status into the final format of the theatre list. The service shall enable the user to record and/or amend free text information relating to the patient booking.
125.3 125.3.1
125.3.2
125.3.3
125.3.4
125.3.5
FINAL 1.0a
Page 424 of 607
ICRS
Requirement 125.3.6 The service shall enable the user to record and/or amend details of the consultant/speciality and surgeon relevant to the patient booking. Whilst the list is in draft format, the service shall allow users to transfer a patient or group of patients from one list to another - on any day. The theatre list shall display the number of cases on the list, and where printed a page number, and the number of pages together with date and time of printout. Once the theatre list is in the final format, where a case is cancelled or abandoned, the user shall be prompted to select a reason from a pre-defined drop down list. The service shall provide the facility for users to define reasons for cancellation and to reverse a cancellation. The service shall allow for cases to be rescheduled if either they or the session is cancelled. This shall take account of urgency, specialist equipment and staff etc. (See also section 3.20) When cancelling a session the service shall be able to retain the name of the original consultant, record a reason for cancellation, date, time and who cancelled whilst still being able to reallocate the session to someone else for the same location. The service shall record where a cancelled session has been transferred for use b another consultant y or another speciality. The service shall allow HCPs to book cases into theatres, day surgery and endoscopy etc. where appropriate, utilising appropriate booking rules into specified slots. The service shall enable a user to book one or more operations for a patient. Booking details shall include: patient name; patient identifier; planned operation; operation type (emergency, scheduled etc.); and
Required Response
125.3.7
125.3.8
125.3.9
125.3.10
125.3.11
125.3.12
125.3.13
125.3.14
125.3.15
FINAL 1.0a
Page 425 of 607
ICRS
Requirement 125.3.16 critical care unit bed needed etc.
Required Response
The service shall inform interested parties (e.g. ward, other consultants involved etc) of the intention to operate. .
125.3.17
The service shall produce a theatre register, which complies with all current legal requirements and is capable of modification to support future changes in legislation. The operating list shall display all relevant items ordered or required e.g. bloods, radiologist, x-ray, specialist equipment etc. This shall be informed by reference to ICP, patient weight, relevant operation, Waterlow score etc. The service shall inform staff of required tasks within theatre, based upon theatre schedule. These shall include links to requests for: patient transport, porters, recovery etc. Recording Theatre Activity The service shall record planned activity separately from actual activity, for the purposes of utilisation analysis. The service shall automatically enter the consultant in charge of patient and operating surgeon if different for each case, if these have already been recorded on the theatre list. The service shall allow clinical coding using the coding facilities detailed in the core requirements section. The service shall link complexity to procedure codes displaying appropriate complexity in the Patient Record. The service shall enforce the requirement to record by name, Unique Personnel Reference Number (UPRN), staff grade and role all persons present in a theatre during a case. This shall include: surgeons and anaesthetist; observing surgeons anaesthetists; anaesthetic nursing staff;
125.3.18
125.3.19
125.4 125.4.1
125.4.2
125.4.3
125.4.4
125.4.5
and
observing
FINAL 1.0a
Page 426 of 607
ICRS
Requirement 125.4.6 scrub Nurse; circulating Nurse; SODP/SODA; ODP/ODA; student; and visitor (pre-defined drop down list stating purpose).
Required Response
The service shall provide the facility for a user to create a staff record for any unregistered staff member assisting in the case to include their role, grade and UPRN. The service shall, where applicable, alert the ward and notify the porter of the theatre that the patient shall be delivered to. The service shall track the patient throughout the intra-operative phase and shall record the times of the following elements in the theatre process: sent for; arrived; anaesthetic Started; in theatre; operation started (knife to skin); operation finished; in recovery; fit to go/transfer to critical care; gone; and nurse back.
125.4.7
125.4.8
125.4.9
The service shall provide the facility to record reason for delay of any of the events (from a pre defined drop down list). It shall provide the facility to record outcome from pre-defined list, and shall include: planned operation performed; planned operation and others performed; cancelled; abandoned; or patient died.
125.4.10
The service shall provide the facility to record type of anaesthesia administered from a pre-defined list, to include: general anaesthetic. epidural; or
FINAL 1.0a
Page 427 of 607
ICRS
Requirement 125.4.11 general & epidural.
Required Response
Where local anaesthetic is administered, the service shall prompt for reduced event timings (as usually no recovery is required), to include: anaesthetic started (local); operation started; operation finished; patient fit to go; and gone.
125.4.12
The service shall record an Anaesthetic profile for each case from the following headings: induction; maintenance; relaxants; analgesics; IV Fluids; and local techniques.
125.5 125.5.1
Clinical Notes & Activities The service shall provide free text facilities capable of presenting specialist descriptions, such as for dental services. The service shall provide the facility to record clinical, anaesthetic or nursing procedures and record who did what. The service shall able to record and/or amend the anaesthetic status (ASA grading) of the patient. The service shall collect anaesthetic data including user definable pre-assessment data fields, anaesthetic data, tourniquet time on, off etc. and free text. The service shall record the final count of swabs, instruments etc. and alert if different from the start count. The service shall record the number and type of drains inserted and other materials left temporarily in the patient. The service shall record multiple implant or prosthesis used with model type, Implant product code manufacturer, and size and serial/batch
125.5.2
125.5.3
125.5.4
125.5.5
125.5.6
125.5.7
FINAL 1.0a
Page 428 of 607
ICRS
Requirement number. 125.5.8 The service shall record the death of a patient during a procedure. The service shall record both Clinical and NonClinical Incidents. The service shall generate a printed summary of the information produced during the operation in order to allow for written signatures of personnel (4 scrub persons, 4 check persons and 2 anaesthetic assistants) for legal and audit purposes. The service shall produce the Operation Note. Stock Control/Procurement The service shall provide stock control, including the facility to track and trace all instrument sets and soft packs. Each bidder shall state its approach to interfacing to procurement systems to enable ordering of specialist equipment. Where specialist equipment is required for a particular procedure, a status flag on case record i.e. ordered, received and available shall indicate this. The service shall display actual stock usage for a selected stock item, location and period of time to include: 125.6.5 consumable item number; consumable item; consumable location; actual start date and time of usage; session; patient; consultant, and specialty etc.
Required Response
125.5.9
125.5.10
125.5.11 125.6 125.6.1
Each bidder shall describe how the links will be made to existing stock systems.
125.6.2
125.6.3
125.6.4
The service shall issue and record stock usage at theatre, session, patient and consultant level. Equipment Management The service shall provide and maintain a theatre
125.7 125.7.1
FINAL 1.0a
Page 429 of 607
ICRS
Requirement asset register, which includes a locating system. 125.7.2 The service shall allow for equipment to be uniquely identified and added to the theatre asset register. The service shall hold safety information against each item of equipment. It shall also generate advance notice of any periodic checks required. The service shall allocate equipment to an individual theatre and/or case and shall assign a record of that use to the patient theatre record. The service shall hold individual or grouped maintenance schedules for equipment items. Advanced warning of impending maintenance shall be available. The service shall maintain decontamination records for each item loaned or received from other internal or external locations. Each bidder shall state its approach to interfacing to existing asset register systems. Staffing The service shall record staff skills against each staff member, in order to allocate staff to theatre sessions or operations and to support the creation of viable rosters. The service shall manage the allocation of annual, special and study leave for all staff. The impact of this on any future planned lists shall be available. The service shall provide attendance records by staff member and group, according to user defined criteria. The service shall include the ability to analyse nonattendance by type e.g. staff type or grade and reason for absence. The service shall maintain staff attendance records by at least site, location, theatre, session and procedure. The service shall record, as a minimum, hours
Required Response
125.7.3
125.7.4
125.7.5
125.7.6
125.7.7
125.8 125.8.1
125.8.2
125.8.3
125.8.4
125.8.5
125.8.6
FINAL 1.0a
Page 430 of 607
ICRS
Requirement worked and overtime. 125.8.7 The service shall maintain staff training and development records including health and safety training etc. All of the above information may be held in a Human Resources System or the national Electronic Staff Record, and if so, the LSP is asked to describe how it shall be available to the solution. Cost Recording The service shall record the use staff, rooms (theatres) and supplies, including medical gases against an individual theatre case. The service shall record the use of specified consumables (either specialty, theatre or site specific). The manufacturers product number, the product and manufacturers name, product description, pack size and unit cost shall identify each consumable item. The service shall provide a method of quickly identifying and recording the use of consumables, e.g. barcodes. Integration And Interfaces The service shall pick up the diagnosis and proposed operation, procedure codes and descriptions from the core ICRS system and display in relevant fields throughout the solution. When a case is cancelled or abandoned from the theatre list, the service shall prompt the user to confirm that patient shall be placed back on the waiting list and if user responds YES, it shall do this automatically. The service shall link special equipment to procedure codes indicating to user when equipment availability is a pre-requisite for that procedure. The service shall interface with medical equipment such as cardiac monitor, oxygen monitor, blood gas machines, anaesthetic equipment etc. in real time.
Required Response
125.8.8
125.9 125.9.1
125.9.2
125.9.3
125.9.4
125.10 125.10.1
125.10.2
125.10.3
125.10.4
FINAL 1.0a
Page 431 of 607
ICRS
Requirement 125.11 125.11.1 Theatre Trays The service shall hold separate files for each tray and each instrument, which shall include photographs or other images where appropriate. The service shall instruments/items. build a tray by listing
Required Response
125.11.2
125.11.3
The service shall allocate a unique ID# to each tray. These shall be grouped into categories. The service shall indicate which items on a tray are costed to an original purchasing department. The service shall have the following functions: tray category and tray description; inventory and charge numbers; manufacturer and Manufacturer Catalogue Number; tray item list; material cost based on tray item components; tray reprocess time and targeted turnover time;direct labour cost component based on tray reprocess time; overhead cost allocation; minimum stocking level, re-order lead times, and shelf life; item Description; inventory and charge numbers; pack Size, units per pack, and minimum order quantities; cost and charge per unit; component reprocess time, reprocess cost, and overhead allocation for instruments; primary and secondary vendor information. instrument serial number; counting usage of each item with a user defined maximum usage indicator specified by individual item. An alert shall be generated when this limit is exceeded; and calculate average usage over user defined periods.
125.11.4
125.11.5
125.11.6
The service shall have the following functions to enable the tracking of trays and instruments: issue date, time, where issued and by whom; received date, time, by whom, and whether or not the tray was complete;
FINAL 1.0a
Page 432 of 607
ICRS
Requirement 125.11.7 tray packed date, time, and by whom. sterilised date, time, by whom, and sterilizer cycle number; acceptance date, time, and by whom, and sterilizer cycle number. display historical status of all tray activity.
Required Response
The service shall automatically calculate elapsed time performance for: issue/surgery start; issue/surgery stop; issue/received; issue/tray packed; issue/sterilised; tray packed/sterilised. surgery stop/received (optional). surgery stop/sterilised. surgery stop/tray packed. received/tray packed. received/sterilised. packed/sterilised. sterilised/issued. issued/theatre/department. theatre/department/surgery start (optional); and tray returned.
125.12 125.12.1
Tray Management The service shall check planned procedures against availability of trays (the theatre may not book cases if the tray is not available). The service shall record the method of sterilisation required for each tray e.g. sterilise, disinfect only. The service shall record that a tray is incomplete with an indication of which items/instruments are missing and the reason. The service shall identify the current location of each tray and its issue status. The service shall have a user-defined label facility, including barcodes. The service shall record the times of each process and the individuals responsible for each action including checking.
125.12.2
125.12.3
125.12.4
125.12.5
125.12.6
FINAL 1.0a
Page 433 of 607
ICRS
Requirement 125.12.7 125.12.8 The service shall record items for repacking. The service shall identify sterilisers and steriliser runs uniquely, and record them against an individual trays process. Anaesthetics The service shall integrate and display clearly on screen all information relevant to the anaesthesia. This includes vital signs, ventilation parameters, respired gas concentrations, ventilator settings, drugs given (with doses and total doses calculated), fluids given (with totals), fluid output, and timed flags for clinical notes/comments. The service shall provide single keystroke access to pre-operation assessment. Access to other functions including, but not restricted to, investigation results, referral letters, clinical notes, and care plans shall be possible with editing facilities. The service shall show drugs and fluids on the anaesthetic screen. The service shall record an anaesthetic assessment for a patient in advance of the procedure and that information shall form part of the anaesthetic record. Anaesthetists give many drugs and fluids during the theatre visit. The service shall record these as part of an anaesthetic graphical record which integrates vital signs, monitoring and other clinical data. the service shall add events to the anaesthetic time line which shall include: 125.13.7 the administration of drugs, fluids and blood; physiological events suffered by the patient; relevant events in the surgical process; and the ability to record the gases used and the concentrations and volumes of each.
Required Response
125.13 125.13.1
125.13.2
125.13.3
125.13.4
125.13.5
125.13.6
The service shall record the techniques and equipment used. The service shall record the sites of anaesthetic interventions including vascular access and spinal/epidural levels.
125.13.8
FINAL 1.0a
Page 434 of 607
ICRS
Requirement 125.13.9 The service shall meet the requirements of the Association of Anaesthetists for appraisal, junior doctor supervision and clinical audit. Critical Care The service shall document defined patient interventions and observations. These may be single or recurring events. It shall record staff involved, lines etc. used and remaining in situ. with date for removal, any sutures and date for their removal, any associated tests needed and any equipment to remain with the patient. The service shall take account of the specialised nature of critical care patients and the need for some specialised protocols to include: Dialysis; Nitric oxide usage; Mode of ventilation; and specialised bed/cot usage. The service shall support these protocols being updated and altered over time as new treatments become available. Data Collection The service shall use event markers (coded and free text) to highlight automatically collected data, which are potentially in error or an artefact (for example arterial line disconnected from patient for any reason). The service shall record daily category of care. The service shall allow the sample interval for data collection from connected devices, e.g. monitors, pressure transducers etc. to be user-definable or to be set against specific trigger values (e.g. BP falls below critical level). The service shall record all fluid inputs and outputs and calculate the fluid balance (taking account of insensible loss). Data Manipulation The service shall allow real time manipulation of data according to user definable rules and formulae
Required Response
125.14 125.14.1
125.14.2
125.14.3
125.15 125.15.1
125.15.2 125.15.3
125.15.4
125.16 125.16.1
FINAL 1.0a
Page 435 of 607
ICRS
Requirement to include: totals, running total for user definable periods (for example total urinary output since arriving on ITU and cumulative urinary output in last 24 hours); average and rolling average over any user definable time period; range; minimum and maximum value of any variable over user definable time periods and obeying user definable rules (for example minimum platelet count in first 24hrs of ITU admission); the ability to calculate new data items according to any user definable formulae and to store these data items for further access or calculations (for example mean urinary output over 6 hours calculated as mls/kg/hour); and the ability to use any calculated data items in any further formulae including rules for alerts.
Required Response
125.17 125.17.1
Data Display The display in critical care areas shall replace the present paper charts used currently. The display in critical care areas shall be userdefinable to suit various critical care specialties. The service shall display present individual patients vital data continuously real time (and with trends) without screen blanking due to time out. Where data is automatically collected from instruments and monitors, the display of this data as a graph shall automatically advance along the graphs x-axis where this represents time to give a real time representation of the data. The service shall be able to display fluid balance as total input in user definable time periods. The fluid balance shall be filterable by fluid type into subtotals in real time (for example crystalloids, colloids and blood). Where multiple fluid inputs or outputs are displayed it shall be possible to filter the view to display only one type of fluid. Graphical Display Of Data
125.17.2
125.17.3
125.17.4
125.17.5
125.17.6
125.18
FINAL 1.0a
Page 436 of 607
ICRS
Requirement 125.18.1 The service shall display numerical values and graphical trends on the same screen. The service shall allow in real time: user definable axis scales and axis intersection values; time line display with time as X-axis for the main display. There shall be a user definable pick list of convenient scales for the X-axis; user definable multiple X-axes for x-y data display of clinical data; user definable multiple Y-axes with user definable scales allocated for different data sources; user definable positions for all Y-axes on screen; ability to hide/uncover Y -axes and associated data with cursor; user definable presentation style of the data using commonly accepted graphing techniques e.g. floating bar graphs, connected lines, individual symbols with user choice of colours and symbols.
Required Response
125.18.2
125.18.3
The service shall generate a graphical view which allows simultaneous visualisation of systolic BP, Diastolic BP, pulse, temperature and other variables such as can be seen in the present paper based vital signs charts used by most wards and critical care areas in the UK. Data Sets The service shall capture, display and report on all the data items included in the following data sets: the ICNARC dataset; APACHE II data sets; and Augmented Care Period minimum data set. the service shall support the West Midlands version of the British Association of Peri-natal Medicine data set.
125.19 125.19.1
125.19.2
The ICNARC dataset is updated regularly and the LSP shall ensure that the most recent version is included in the service. Transfer Data
125.20
FINAL 1.0a
Page 437 of 607
ICRS
Requirement 125.20.1 All transfers to/from the Critical Care Unit (CCU) shall be logged as being for clinical or Nonclinical reasons. Specific Data Entry Screens The service shall support the registration of Brain Stem Death (BSD) allowing one or two clinicians to enter and authenticate the data required for the fulfilment of the UK BSD criteria. Scoring Systems The service shall provide the facility for any critical care area to implement any national and/or local scoring system. Clinicians shall have the tools to develop such scoring systems or modify them without the need for intervention of the bidder, for example scoring systems such as the Glasgow Coma scale, Therapeutic Intervention Scoring (TISS) or similar (SOPRA), Sedation score and Waterlow scores.
Required Response
125.21 125.21.1
125.22 125.22.1
FINAL 1.0a
Page 438 of 607
ICRS
SPECIFIC COMPONENTS 151 Primary and Community Care Overview This module specifies the requirements for the service to support the delivery of Primary and Community Care. It is envisaged that the generic functionality, which has been defined in other modules, will support a majority of Primary and Community Care requirements, tailored to meet the specific needs of this care setting as required. This section defines the specific application of this functionality in meeting Primary and Community Care needs. The way care is d elivered in these areas is changing and expanding significantly and information solutions need to be sufficiently flexible to meet their rapidly evolving information requirements. A new generation of integrated systems need to be developed and implemented to ensure that patient care is supported across organisations and that healthcare professionals treating patients have secure access to the information and services they need. The emphasis of change is on services being delivered within the home, thus shifting care from the acute to the primary and community sector. The use of mobile monitoring devices and self management systems will increase. General Practice Special Interest practices and nurse practitioner services are being developed that provide specialist secondary services to clusters of practices. This will require extensive interconnectivity between practices systems and with the ICRS. The service must be able to provide the ability to communicate directly with colleagues in tertiary centres in real time. Health promotion and illness prevention is gaining more prominence and services that enable people to access information and support more easily are being developed often exploiting all forms of communications technologies. Care is provided in any setting that people may live, work or socialise. This includes homeless hostels, colleges and schools, day centres, leisure centres, luncheon clubs etc. Health promotion activity can take place in a variety of places such as market stalls, public libraries, church halls, factories, shopping centres, public events etc. The health professionals working in primary and community care services will be dependant on effective mobile technology and will require functionality that enables them to schedule their work in a variety of settings and record activity and outcomes for groups of persons as well as for individuals with ease. Primary and community care delivers services to the well person not just to those who are ill or who are worried. It encompasses health promotion, illness prevention and support services. Access to these interventions is not necessarily by means of referral. A significant proportion of the service delivery is dependent on the ability to define cohorts of the population with given characteristics to whom preventative and health promotion services can be targeted. This is a key feature of primary and community based services. Primary and community care encompasses working closely with and through the family and carers. Thus the ability to share relevant information within the necessary confidentiality and permission protocols with the family and /or carers and for them to be able to interact with the ICRS is vitally important.
FINAL 1.0a
Page 439 of 607
ICRS
People are used to having open access to their records in many general practices and in their homes. The record in the home is often multi- professional which includes being accessed and used by social care services. Access for patients and their carers to ICRS in a userfriendly manner will therefore need to supported. Primary and community services are cradle to grave services and involve: planned preventative programmes/interventions; discrete specific episodes of care that may or may not incorporate care in other sectors such as acute outpatient/inpatient care; long term management of chronic conditions or disability involving acute exacerbations, requiring reassessment and adjustments to the care plan; and multi-professional teams. The above will apply for most people.
Scope Components The requirements include the following: data standards; patient administration and recording in line with national data standards; messaging (including eBooking); prescribing; and reporting and analysis (including GMS Quality Framework). delivery of care, data take-on, scheduling and ordering; GP practice integration; information management; health economy integration; child health; and patient / carer access. Assumptions Primary and Community Care are closely related integral parts of the wider health community and the systems which support them need to reflect that. Accordingly, there is no definition of a discrete "Primary or Community Care system"; only that functionality which is in some way different or unique in Primary and Community Care. The Primary Care Team should be seen as the manager of care having responsibility for the care of the person whilst registered with that practice. Consultants and others will have responsibility for the duration of the episode that was referred to them.
Dependencies Much of the interoperability and sharing of GP information is dependent upon the delivery of technically robust and professionally-acceptable solutions to other areas of delivery within the NHS.
FINAL 1.0a
Page 440 of 607
ICRS
Benefits and Outcomes There are significant benefits for patients and C linicians in enabling communication across Primary Care and Community Care. In one SHA, community nurses currently register about 28,000 new patients a year using paperbased registration forms. It is anticipated that, by sharing and accessing a common PDS the requirement for community nurses and AHPs to register patients will be reduced to a small number of exceptions (e.g., new babies whose records have not found their way on to the PDS. It is also anticipated that the patient registration process will be simplified. AHPs and community nurses process several thousand referrals each month. The referral processes vary, depending on the professions and locations involved (e.g., some referrals are handled by GP practices, whilst others are dealt with centrally). Referrals may be received via letter, telephone, verbally, self-presentation or e-mail. Some referrals are date stamped and assessed to determine whether they are appropriate before being passed to the relevant professional or returned to the referrer. Staff may refer patients on to other external services/professionals and also those working within the same organisation; e.g., from a Health Visitor to a speech and language therapist. It is envisaged that the service will provide an opportunity to streamline and standardise the referral processes. Current Situation Current Primary Care systems are essentially GP-based systems, implemented on a per-practice basis. Community systems in general have traditionally been organisation-centric systems designed to meet administrative, rather than clinical, needs. However, a number of Community systems have been used to manage child health programmes such as: child health surveillance; immunisations and vaccinations (including school health programmes); and child protection.
Functionality to share data between systems has not been realised to date. There are, however, pilots in progress; for example, the transfer of entire clinical records between GP systems (GP2GP), based around an HL7 Message standard (details may be found at the URL, <http://www.nhsia.nhs.uk/gp2gp>). Desired Benefits and Outcomes To: Patient Improve patient care through a single health record, on-line appointment booking and electronic transfer of prescriptions, as implemented for a Cluster by an LSP. Continuity and personalisation of care. Access to personal data of which he or she is the subject in accordance with NHS policy and legislation.
FINAL 1.0a
Page 441 of 607
ICRS
Increase patient confidence in the service being offered; patients to be confident that information about them and their history of care is managed in a secure and confidential manner. Patients to be reassured that their healthcare professionals have access to appropriate information held on other systems for their clinical care and treatment. Increases patient access to and enriches health information to support their education and selfcare.
Improves speed and reliability of patient centered communications. Clinician Faster access to patient information, and faster and more certain referral and booking processes. Ability to know who is involved in caring for the patient. Ability to know the current status of the patient, referrals and bookings. Clinicians to access appropriate information about individual patients held on other systems for the clinical care and treatment of the patient. Inter-communication between clinical and administrative systems. Support for the legal requirement to have an accurate historical record of care. Remote access to research papers, reviews, guidelines and protocols via the Internet and NHSnet.
Clinicians to access the knowledge base of health care at the point of contact with the patient. Manager Integration of data is an enabler for business change; e.g., electronic prescribing. Availability of high quality data upon which to plan the service and its provision. Helps to improve patient care, for the individual patient and group of patients. Raise awareness of the needs of the patient population as a whole (e.g. a GP practice or PCO patient population) allowing the NHS organisation to look at the needs of specific groups of patients as well as the individual. Enable the identification of groups to target for particular interventions and packages of care (e.g. chronic disease register); Audit of better data gives a more accurate reflection of the care provided; facilitates the process of clinical audit and governance. Motivate and encourage staff; encourage staff to work as a team can be used as a communication tool. Reduce duplication of work and increase efficiency within the NHS organisation. Enhance evidence-based practice and performance targets (e.g. the new GMS Contract Quality Framework). Improve commissioning and resource planning.
FINAL 1.0a
Page 442 of 607
ICRS
Support epidemiological monitoring and public health services. Improve and extend capacity for research. Summary Record The Spine is a summary of the treatment/interventions which have been provided for the patient. When the system has been operational for a few years (about 2 to 3) the increasing availability of computerised summary Patient Records should lead to a reduction in the retrieval of paper-based Patient Records. It should also increase the use of common terminology amongst staff, specifically AHPs and community nurses, with GPs, and as links develop, with other h ealth and Social Care organisations. Typically, the summary would provide: patient demographic details; referrals made on behalf of the patient; appointments attended by the patient; contacts with the patient - date last seen for each professional involved in patients care; contacts, distinguishing between face-t o-face and other types of contact; coded data (e.g., Read - key diagnoses, treatments, drugs) with descriptions relating to the patients diagnosis/treatments;
expansion of abbreviations used by Clinicians; planned future events; clinical alerts; and professionals currently involved in the patients care and their contact details. Community based services have a concept of caseloads for either individual care practitioners or a team such as a rehabilitation team. They will receive referrals and allocate them to caseloads. Where they cannot allocate a referral immediately to a caseload the referral may be placed on awaiting list. In some cases the person is seen and assessed and then placed on a waiting list of the particular intervention or therapy. When care practitioners are on leave or off duty another colleague may cover their workload. This will require the ability for colleagues or members of the team to access the same Patient Record. Assess Patient (Carer) This function involves the collection of information from a range of sources in order to build a profile of patient (and carer) needs. This can be in a multi- or uni-disciplinary context. This facility should enable the collection of assessment information to be more complete and consistent. It should provide improved access to assessment records for appropriate staffs (see Module 104). Details of the assessment are stored for future reference and to facilitate the production of a treatment/care plan. There are three levels of assessment documentation required:
FINAL 1.0a
Page 443 of 607
ICRS
core assessment details shared with and common to multi-professional staff; specialist assessment details specific to a profession, but sometimes shared with other professional staff; and
assessment summaries shared with multi-professional groups and external bodies. Assessment details, in some cases at summary level, are passed to various external bodies. Deliver Care Delivering care can take a number of forms; for example: contacts with patients; non-face to face contacts (e.g., telephone support); and liaison with or about patients. Delivering care usually involves a staff member making an assessment, then carrying out investigations and delivering treatment or a service. Consequently, in some cases it is important that staff can easily allocate equipment and order tests, consumables or transport, and that some practitioners (for example, but not limited to, nurses, paramedics, emergency care practitioners) are also trained to prescribe and administer drugs. There are about 535,000 face to face nursing contacts with patients each year. The service shall benefit staff by enabling a full and consistent record of contacts with patients to be captured, including non-face to face interventions. The work arising from these contacts, such as ordering equipment, arranging appointments and generating correspondence, should be easier for staff as a consequence of using the system. Some of these contacts may involve groups of patients; e.g., self-help groups to give up smoking. Treatment/Care Plans Formal evaluations of a patients care will occur both on a planned and an ad hoc basis. The review of care may be either uni-or multi-disciplinary. The review will involve comparing the patients current condition against the goals and objectives set in the treatment/care plan. To address the more complicated needs of some patients, there may be a need for several plans. For example, for multi-disciplinary cases there may be a high level plan which describes the overall care across the various disciplines, with each individual discipline involved producing a more detailed uni-discipline plan to address each individual need.Produce Treatment/Care Plans Treatment/care plans describe the characteristics of the treatment or care which is being provided (or will be provided) to address the patient needs and objectives identified by the assessment. Typically, a plan would give details of the type of treatment/care, the professionals or others involved, and the frequency of any interventions or reviews. The service shall provide functionality to support ICPs, in accordance with emerging local and national guidelines and standards. To address the more complicated needs of some patients, there may be a need for several plans. For example, for multi-disciplinary cases there may be a high level plan which describes the overall care
FINAL 1.0a
Page 444 of 607
ICRS
across the various disciplines, with each individual discipline involved producing a more detailed unidiscipline plan to address each individual need. Schedule Patient Appointment/Diary Management/Non-Clinical Staff Activity The management and scheduling of clinic sessions, appointments and follow-up work arising from appointments should be made easier for staff. This functionality may be required from a number of points within the system. The function should include the facility to schedule: an assessment; a patient treatment/intervention; surveillance/review; updating tests; e.g., neurological; a non-face to face contact; e.g., review of patient by telephone; a group session/clinic; a training course attendance; a case conference; and meetings. Appointment requests may be generated by a number of functions, such as referral or assessment, or due to other contacts with the patient or other professionals or services. Appointments may be scheduled at any location to be held at any location; e.g., the patients home, a GP surgery, a community hospital, clinics, etc. Caseload Management The service shall provide improved caseload management. Managers (and staff) need to be able to monitor workload and make adjustments to enable the best use of resources and provision of care to patients. Waiting List Management Waiting lists are currently managed by clinics, depending on the specialty or service or caseload as above. Discharge/Outcome There are currently about 12,000 discharges from the community nursing service alone per annum. The system will enable better notification of discharge, reducing the administrative burden on staff and inappropriate allocation of resources; e.g., equipment and appointments. The discharge process may include retrieval of equipment on loan and unused supplies. Alert/Critical Information Screen Clinicians need to be made aware of any potential risks to themselves or the patient when delivering care. When the risks are patient -specific, this might be achieved by displaying an alert flag on the screens associated with that patient; e.g., the screen header. There is also a need to convey more general critical information; e.g., hazard warnings about potentially faulty equipment. Critical patient information e.g. allergies, blood group, life dependent medication etc. shall also be displayed Chief medical officer alerts.
FINAL 1.0a
Page 445 of 607
ICRS
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Integration of GP practice systems. Support for GMS Contract and widespread implementation of interoperability initiatives currently in pilot. Delivery of current functional richness maintained.
Minimum Level to Be Achieved by December 2006 (Phase 2) 100% implementation of interoperability initiatives currently in pilot. >50% implementation of list in "Benefits and Outcomes" section, including patient access.
Target for 2010 All interoperability initiatives delivered. Appropriate access available, regardless of location. Knowledge management / real-time audit to be implemented. LSPs are invited to state any ability to deliver in excess of this minimum within the time frames stated. Patient records shared across all care sectors. LSPs are invited to state any ability to deliver in excess of this minimum within the time frames stated.
FINAL 1.0a
Page 446 of 607
ICRS
Overview Requirements Requirement 151.1 Overview An integrated service which offers all Clinicians in Primary Care within a defined health community access to a common set of functionality and a common dataset. 151.2 Benefits and Outcomes The service shall deliver improved availability of patient information across the community. The service shall deliver significant benefits through joining-up different care sectors. 151.3 Implementation and Phasing The overview delivery expectations have been set out above. More specific implementation plans will be agreed with each LSP. Each bidder shall describe how it would deliver the benefits and outcomes from this module. Each bidder shall describe the types of benefit it would expect to see, and how it would help to deliver them. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority. Required Response Each bidder shall describe its approach to delivering this module.
151.4
Overview Requirements
Detailed Requirements Requirement 151.5 The service shall support community service caseload/mix management. The service shall allow referral and acceptance into a service and then allocation or referral to a caseload. The service shall enable a referral to be ascribed to a team or a care practitioner caseload. The service shall allocate a referral to a caseload governed by rules of assignment. For instance: the allocation of children to a school nurse via the school they attend or a new birth Required Response
151.5.1
151.5.2
151.5.3
FINAL 1.0a
Page 447 of 607
ICRS
Requirement to a health visitor by the registered GP practice or home address. 151.5.4 The service shall allow authorised members of the team to access a record when the colleague is not available or for purposes of supervision. The service shall allow discharge from the caseload without necessarily discharging from the service. The service shall allow reporting of waiting time by case load or service. The service shall provide reports of referrals received, accepted on and discharged from a caseload in a specified period. The service shall enable a care practitioner to record the number of persons attending a group or health promotion event. The service shall enable a care practitioner to record the length of time spent on activities such as groups, preparation for groups, case conferences, liaison work etc. in their diary. The service shall permit the recording of the length of time spent in a patient/client contact. The service shall facilitate maintenance of common details for multiple Patient Records to support group activities. For instance a school nurse being able to record the polio vaccination, batch number and date in each child's record without opening each record individually (where the date and batch number are the same) or a physiotherapist entering the fact that each person has attended a group therapy session.
Required Response
151.5.5
151.5.6
151.5.7
151.5.8
151.5.9
151.5.1 0 151.5.1 1
FINAL 1.0a
Page 448 of 607
ICRS
153 - ACUTE SERVICES Overview In OBS1 this module specified the requirements for the service to provide the specific sub-modules needed to support Acute Care. These requirements are now listed under generic services. Scope Components To a greater or lesser degree, all the generic modules will form elements of acute functionality Assumptions Most sites already have basic Acute Care systems in place, although a significant minority are legacy applications. Current Situation Over the last few years, NHS hospitals have been upgrading/replacing their IT systems to try and meet the targets stated in "Information for Health." Depending on the level each hospital is at, the situation is variable. Benefits and Outcomes Many of the benefits to patients, Clinicians and managers are in administration and efficiency. Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) It is expected that at least 30% of hospital systems will be conforming to the common requirements around clinical communications and interfaces stated in Part III of this OBS.
Minimum Level to Be Achieved by December 2006 (Phase 2) It is expected that 100% of hospital systems will be conforming to the common requirements around clinical communications and interfaces stated in Part III of this OBS.
Target for 2010 Over the lifetime of the project, it is expected that the reliance on organisation-specific requirements will be replaced by a series of generic functions, and that full utilisation/integration with the Spine will have been achieved.
LSPs are invited to state any ability to deliver in excess of this minimum within the time frames stated.
FINAL 1.0a
Page 449 of 607
ICRS
Overview Requirements Requirement 153.1 Overview Required Response Each bidder shall describe its approach to delivering the expectations for acute care. Each bidder shall describe the benefits it would expect to see from Acute Care functions, and describe how it would provide quick win benefits in parallel with the wider project requirements. Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
153.2
Benefits and Outcomes The implementation of Acute Care functionality is critical to the implementation of care records.
153.3
153.4
FINAL 1.0a
Page 450 of 607
ICRS
154 - AMBULANCE SERVICES Overview This module specifies the requirements for data collection and reporting for ambulance services. Scope In the future, it is likely that emergency medical services (EMS) staff will have much more responsibility for treating patients outside the hospital and en-route. They will make clinical judgements about the best care pathways for the patient; they may leave them at home with suitable care organised (e.g., through Social Services or a GP); or they may deliver the patient directly to the hospital department best suited to their further treatment. The inclusion of thrombolytic therapy in the NHS Plan is a practical example of these changes. These developments require establishing communications and data exchange with many NHS departments and some external organisations. EMS staff are likely to require computer-based decision support systems encoding the treatment and triage protocols. The systems that collect the information on the ambulances are likely to change as rapidly as technology and budgets allow. This makes it impractical to define the service in terms of the physical system in operation on the ambulance. The information that any system collects, however, is of a very different nature. To remain useful and to allow comparisons of clinical and operational effectiveness over time, the type of data collected must remain consistent. In addition, to support analysis and reporting across ambulance trusts, it must conform to a national standard. Components Ambulance staff are one of the staff groups covered by the generic requirements supported by ICRS. All the generic ICRS functionality needs to be available for them. This must be borne in mind when considering the very specific ambulance service aspects, as detailed below. The LSP shall deliver a core dataset system, which defines the data to be collected; its formal, computer-based representation; data exchange mechanisms; and a system to store and report on the information. This will be long lived, changing infrequently, and should be adopted across all Ambulance Trusts that wish to take part in national analysis and review. It will include: a defined common core dataset (e.g., JRCALC); a defined formal computer data representation, suitable for data exchange (e.g., an XML schema); a core set of analysis/reporting functionality. This must include a definition of any data required from external systems in order to provide particular reports. The reports would include views based on patients, EMS staff and Ambulance Trust operations; and the system requirements for short-term data storage on the ambulance and long-term storage within the Ambulance Trust.
Exclusions Requirements for a data collection system have not been defined at this stage. The data collection system will be used to collect the data on the ambulance. This is the interface that the ambulance crew will use in their day-to-day operations. It could be a dedicated system (e.g., electronic form) or could define the interface between a decision support system and the core electronic patient reporting dataset system. This component of the system could be defined within a single Ambulance Trust (or trust group); and it may change frequently as operations and technologies change.
FINAL 1.0a
Page 451 of 607
ICRS
This specification is not attempting to address requirements for ambulance command and control systems. Benefits and Outcomes The use of an electronic patient reporting system has many potential benefits over the conventional paper-based PRF. These include: elimination of paper handling and the requirement for storage space; potential for more complete and accurate data collection (e.g., automated data collection); more legible data collection, where free text is entered; support for more timely and accurate Clinical Audits and reporting through the capture of structured data in an electronic format, including t e ability to monitor progress against NSF h targets; reduction in the resources required to conduct Clinical Audits; e.g., data entry into a database, the transfer of data to microfiche, manual analysis and reporting procedures, etc; the ability to communicate patient data from the ambulance to the A&E department during transit to the hospital; the ability to integrate patient data with A&E and hospital systems; improved confidentiality of patient data, facilitated through secure storage of encrypted data; and support for education and training activities.
Previous Experience/Lessons Learned Currently, the PRF is a paper form used to collect data about the patient and their treatment during the ambulance trip. It contains both demographic and clinical information about the patient and information regarding the ambulance journey (e.g., clock times). In the existing organisation, the main clinical relationship is between the ambulance and the A&E department. The crews stabilise the patients and transfer them to the least busy A&E location within their area. Communication is limited to the PRF form and verbally, by phone from the patient's home and direct on arrival at the hospital. This model is under some pressure from plans and targets within the NHS. There is a move to treat patients more efficiently and effectively. In a modern ambulance service, relationships may be between many more parts of the health services and Social Services. It may be that patients will be treated by the ambulance crew and left at home with help from a professional carer (e.g., Social Services, or an appointment from the GP) or transported directly to a hospital department appropriate to their continued care (i.e., not necessarily A&E). In this scenario, it is clear that EMS staff will require better training and access to more clinical support systems on the ambulance. The introduction of thrombolytic therapy is good example of this. If thrombolytic drugs are to be administered on admission to hospital, or on board the ambulance (the NHS Plan includes this as a target to be achieved within the next two years), it will be necessary to transmit ECG results to the A&E department in order for doctors to assess the patient's suitability for treatment. This immediately introduces the need for data transmission between the ambulance and hospital-based systems and a means of supporting clinical decisions on the ambulance. In addition to the changes in responsibility for the EMS staff, there are the additional pressures to collect data that can be analysed in order to demonstrate clinical and operational efficiency (the Clinical Governance Framework drives these requirements; for example, patient outcomes could be very useful in assessing treatment pathways). Legal responsibilities are also forcing Ambulance Trusts to collect and retain large amounts of data. The Shipman Enquiry is a recent example that demanded detailed information from at least one Ambulance Trust. To be useful, the data must be consistent, accurate and complete:
FINAL 1.0a
Page 452 of 607
ICRS
consistent - in order to make comparisons or draw wide ranging conclusions the data collected must be consistent across all the ambulance services; accurate - the data collected must truly represent the activities of the ambulance crews; and complete - the crews must record all the appropriate activities.
To support consistency, the ambulance services must establish a common minimum dataset e.g., JRCALC) that any electronic patient reporting must support. To support accuracy and consistency, the service must fit into the day to day operations of the ambulance crews. The collection service must not hinder their work, and they must be able to see real benefits from its collection. If they are driven to circumvent the system in order to concentrate on the "real" work of the service, the data will not be trustworthy and will undermine the whole system. Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) 20% implementation of ePRF and collection of minimum dataset information.
Minimum Level to Be Achieved by December 2006 (Phase 2) 100% implementation of ePRF and collection of minimum dataset information.
Minimum Level to Be Achieved by December 2010 (Phase 3) 100% implementation of ePRF and collection of minimum dataset information.
Overview Requirements
Requirement 154.1 Overview Required Response Each bidder shall describe its approach to delivering requirements for ambulance services. Each bidder shall describe how it will work with third party application service providers to provide information and skills as required to enable existing and new applications to be integrated with the e-PRF system. 154.2 Benefits and Outcomes The service shall deliver a number of benefits through the introduction of the electronic patient reporting form. The service shall support the objectives and targets set out in the key NHS strategy documents, including: the NHS Plan; and the NSF for Coronary Heart Disease. Each bidder shall describe how it would deliver the benefits and outcomes from electronic patient reporting.
FINAL 1.0a
Page 453 of 607
ICRS
Requirement 154.3 Implementation and Phasing The overview of delivery expectations has been set out above. More specific implementation plans will be agreed with each LSP.
Required Response Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it would be able to deliver during Phase 1. Each bidder shall describe the responsibilities it would expect to be assumed by the Authority.
154.4
Detailed Requirements Requirement 154.5 154.5.1 Operation The service shall be extensive. As well as supporting the immediate work processes and IT infrastructure of the Ambulance Trusts, it shall be able to support new functions and processes as they emerge. The service shall be capable of co-existing with existing and emerging ambulance-based systems. Each bidder shall describe its approach to the requirement, including the scope for future flexibility. Required Response
154.5.2
Modern working practices are expected to introduce many more systems onto the ambulances (e.g., telemedicine and decision support). Each bidder shall describe its approach to linking with other ambulance-based applications. Each bidder shall describe the facilities for protecting personal information.
154.5.3
Access to data on the service shall be restricted to authorised users. The service shall support the transfer of data from the electronic patient reporting client to a central electronic patient reporting server. The service shall support remote exchange with the A&E department. data
154.5.4
154.5.5
Initially, thrombolytic therapy will require an exchange with hospital Clinicians. Each bidder shall describe how this would be supported.
154.5.6
The service shall be capable of providing data uploads to A&E systems where suitable interfaces exist. The service shall be capable of pre-populating its data fields with incident data from
154.5.7
FINAL 1.0a
Page 454 of 607
ICRS
Requirement ambulance control centre (CAD) systems where suitable interfaces exist. 154.5. 8 The portable element of the service shall have local wireless communication with the ambulance-based component. The service shall be capable of storing data locally.
Required Response
Each bidder shall describe the communication facilities to be provided.
154.5.9
Remote data exchange should minimise the need for local storage; however, in the event of transmission failure, a local store can prevent data loss. Each bidder shall describe how this will be achieved. Each bidder shall describe the facilities to be provided.
154.5.10
The service shall be able to include data from other electronic systems on the ambulance; for example, ECGs. The types of data collected are likely to increase with time. Video has been mentioned as a desirable option as bandwidth increases.
154.5.11
The service shall have the ability to access other NHS information sources; for example: A&E systems; ambulance control centre (CAD); and Patient Record.
This may be difficult to achieve in the short term where systems are non-standard. This is likely to change as the systems develop. 154.5.12 The service shall have the ability to access information from other organisations (e.g., the police). This is required, for example, to identify potentially violent patients or if there is a dangerous dog in house warning. The electronic patient reporting interface shall be intuitive and easy to learn. Data entry via the electronic patient reporting client shall be at least as fast as the current paper-based system. The data shall be collected in as simple and unobtrusive manner as possible, with as little disruption to the ambulance crews' normal Each bidder shall describe how this will be achieved. Each bidder shall describe the facilities that will be provided.
154.5.13
154.5.14
154.5.15
FINAL 1.0a
Page 455 of 607
ICRS
Requirement procedures as possible. If decision support does become part of the ambulance crews' working practices, the data collection may be transparent to the crew. 154.5.16 The interface shall support the latest innovations in data entry so as to minimise disruption to the EMS staff primary task. The current systems employ clear touch screens with buttons capable of selection by gloved hands. 154.5.17 Retrospective data entry shall be available, as high-pressured situations may force the EMS staff to delay data collection. The service shall be capable of printing multiple copies of a PRF. The service shall be capable of supporting other applications. Examples are: 154.6 154.6.1 training; internet access; and e-mail.
Required Response
Each bidder shall describe user interface facilities that could be provided; e.g., voice-activation.
Each bidder shall describe how data will be entered at a later time.
154.5.18
154.5.19
Each bidder shall describe the facilities that will be provided.
Information Ambulance response times must not be adversely affected by the system. The service shall collect the defined standard dataset. JRCALC defines an accepted minimum dataset. A standard encoding of this should be adopted. In addition to the nationally-defined dataset, the service shall allow the addition of information that users find important; e.g., to support local audit. The service shall be capable of including data from external sources that may not be textbased (binary data); for example, ECGs. The service shall support the exporting of anonymised datasets. Each bidder shall describe facilities for local tailoring and customisation.
154.6.2
154.6.3
154.6.4
154.6.5
FINAL 1.0a
Page 456 of 607
ICRS
Requirement 154.6.6 Standard data SNOMED CT. shall be supported; e.g.,
Required Response
154.6.7
Where appropriate, the service shall allow free text to be collected. Digital signatures shall be supported. The NHS Number shall be supported as a primary identifier. Full Audit Trails shall be collected for data entry and update. The service shall be able to exchange datasets with associated systems (for example A&E and CAD systems). The service shall employ standard mechanisms for exporting information; e.g., the use of XML and its associated recommendations. Information collected by the service shall be capable of inclusion in the wider Patient Record. Operation The service shall be capable of operating with no communication to external systems. Each bidder shall describe facilities for Audit Trails. Each bidder shall describe how digital signatures will be supported.
154.6.8 154.6.9
154.6.10
154.6.11
154.6.12
154.6.13
154.7 154.7.1
FINAL 1.0a
Page 457 of 607
ICRS
160 - NATIONAL SERVICE FRAMEWORKS Overview The purpose of the requirements specified in this module is to support the development of clinical services to patients and their families and carers with particular reference to NSFs and other national and local clinically-focussed initiatives. The NSFs published to date set out standards of care in relation to a number of different conditions (e.g., cancer, coronary heart disease, long term conditions, diabetes, renal and mental health), client groups (e.g. children, older people) and organisations (e.g. Mental Health Trusts). These different areas are referred to here as "domains." The NSFs: specify interventions that are known to be effective; identify models of care that deliver those interventions reliably; provide means to implement improved systems of care; develop audit tools and performance indicators; indicate milestones and goals to monitor progress; identify gaps in knowledge and standards to inform research agendas; and institute a system for reviewing and updating the contents of the NSF in line with medical developments.
The information strategies published in association with the related NSFs are designed to support the standards of NSFs by identifying the information needs of stakeholders for the domains (patients, their families and carers, health and (where appropriate) Social Care professionals, managers, planners and commissioners) and proposing actions that should be taken at both national and local level in order to ensure that stakeholders information needs are met. By the same token, at the heart of the ICRS is a record that ensures, at the point of care, that the health and Social Care professional is fully informed by comprehensive, timely, accurate information and that the patient has a timely record to help them monitor their care and help them make informed choices about the management of their care. Consistent with this approach, the actions in information strategies fall generally into a number of categories, as follows: Information Systems - ICRS: actions to develop information systems, the functionality of which falls within the scope of the ICRS, that will enable care professionals to provide seamless, integrated care, both within the framework of multi-disciplinary teams using care plans and across different organisations and settings; and that will provide patients and, subject to strictly applied security and confidentiality protocols, health and Social Care professionals with the means to access and share their medical records for the purposes of enabling patients to take an active role in the management of their condition, including by empowering them to make decisions that affect their care; Datasets actions for the development of suitable datasets: for generation as a by-product of direct care of patients and for implementation in planned systems; to improve the quantity and quality of condition-specific data; to support clinicians and managers in monitoring performance and outcomes on a local and national basis; for service planning; and to support the commissioning process; Registers the development of registers to support the call and recall of patients;
FINAL 1.0a
Page 458 of 607
ICRS
Standardisation and Consistency of Data actions that call for the standardisation and consistency of data definitions in order to secure a common language both within health care and between health care and Social Care. These actions also include calls to rationalise the amount of data that is currently collected by many different organisations. Standardisation of data structures and content is a key requirement of any information system where data is exchanged and where data is to be extracted for interpretation. It is therefore a requirement of the ICRS as well as an essential dependency for the success of the proposed "National Analytical Service"; Development of the Knowledge Base actions for the development of a knowledge base that will provide all stakeholders, through different but complimentary routes, with the information they require to obtain or provide first-class care. For example, healthcare professionals may refer to evidence-based guidelines provided in the National Electronic Library for Health (NeLH); patients and the public may enquire on NHS Direct Online for information about specific conditions or call NHS Direct in an emergency. These actions also link to the development of the systems referred to above that, for example, may have a requirement for evidence-based information for certain types of decision support. They also link to the provision of and access to information for patients and the public referred to below; Education and Training actions for the education and training of healthcare professionals that will empower them in the use and application of information technology for the better understanding of the data and the information that is available to them; General Information for Patients and the Public actions that call for the provision of general information in a number of different formats to help patients and their families and carers and the general public to have a better understanding about a particular condition. This information may, for example, be delivered face-t o-face, or in the form of leaflets or videos, or may be obtained by logging on to NHS Direct Online or calling NHS Direct. In all cases, however, there is a need for consistent and reliable information delivered in a way that all people can understand.
The information strategy actions supporting implementation of the NSF care standards are, therefore, heavily, although not exclusively, dependent on the ICRS, and bidders will need to be familiar with the implications of the actions in order to support their specification and implementation, both nationally and locally. Furthermore, it is expected that the NSFs and their information strategies that are currently in development will have needs similar to those already published. NSFs announced and in development are for "Childrens & Maternity Services," "Renal," and "Long Term Neurological Conditions". The similarity of the actions across the different NSFs and information strategies indicates that there is a high level of commonality of requirement for information over the different "domains" (see above). This similarity results from the similar types of activities encountered throughout the patient care pathways in association with these domains and should enable systems to be developed that reflect a high degree of generic functionality with a corresponding lesser amount of functionality that is specific to one or more of the "domains". Bidders will therefore need to be aware that the requirements for NSFs are expected to be met through the application of the generic functions described in this OBS. There will, for each domain, be some specific requirements. An overview for each domain is provided in Modules 161-168.
FINAL 1.0a
Page 459 of 607
ICRS
Scope Components These requirements are restricted to: those NSFs and other clinical support mechanisms (together with their supporting datasets) which are defined from time to time; and those datasets, other than NSFs, which also have been nationally-defined from time to time; for example, those for the National Joint Registry, CHAI, etc. The service supports the provision of the required data through a range of Messages. Systems directly supporting clinical (and other) activity should be the source of the required data. Stand-alone systems which collect data away from the clinical (and other) activity through secondary entry of data are not acceptable. It may be that such analytical requirements for NSFs, etc., may be an integral part of a larger analytical environment (whether local or national) or are an integral part of the systems which directly support clinical activity. It is not desirable to have separate systems to handle each NSF separately. Where systems hold identifiable data (especially those for Clinical Audit), they must conform to the confidentiality and security requirements and those of applicable data protection legislation. The base-level clinical activity and resource data should be capable of being analysed and abstracted for any organisational level within the scope of the LSP. Other Requirements The analytical system may stand alone initially, but must be fed directly without re-keying. The reports from the service shall support the required analyses as specified in each implemented NSF and clinical support environment. Clinical data will be passed between clinical systems as required, and the NSF mechanism is not to be used as a channel for such data. Where external environments support monitoring of NSFs (for example the Prescription Pricing Authority), then these are used as appropriate within overall NSF management. The ICRS is not a passive data acquisition system but an enabler of flexible interactive functionality for the patient and their health and social service professionals. Modules 124, 160 and 450 (in Part III of the OBS) should be considered a complementary set of requirements which, together with functions on the NHS Spine, cover the whole range of secondary uses of information. In addition, Module 101 is concerned with the tools surrounding data extraction, manipulation, etc. Benefits and Outcomes Current Situation The datasets which support NSFs and other clinical improvement programmes are generally collected in specialist systems where some or all of the data is manually entered. This creates its own problems. Although this situation may be necessary to support NSFs currently, this is not the strategic direction.
FINAL 1.0a
Page 460 of 607
ICRS
Desired Benefits and Outcomes The difference between the current environment for supporting NSFs, etc., and the future is that data will be collected directly from systems which support the Clinician in caring for the patient. The main benefits sought are as follows: collection and analysis of clinical activity across a complete care pathway, or an ICP, allowing the NHS to determine the best mechanism of providing specific services to the patient; provision of databases suitable for health services research as well as audit purposes; In addition to this, the LSP Services should lead to the following benefits: To: Patient with timely and appropriate information and clinical services, the patient can be fully reassured, with supported monitored self-care; and in addition, the patient has a timely record to help them monitor their care, make informed choices about its management, and understand what care to expect and why it is being offered. Clinician (locally) understanding NSF and other requirements, combined with a responsive appreciation of their current clinical activity, will allow Clinicians to adjust their healthcare provision accordingly; enabling the Clinician to have objective evidence of the quality of care they are providing to the individual patient, their practice population (for Primary Care) and, with other constituent organisations, measure progress towards the goals and standards of the NSFs; and how care is given is fundamental to the implementation of NSFs. This can be supported most effectively by using clinical data collected at source and increasingly from an informed patient in the community. Clinician (nationally NSF bodies, professions, etc.) making sure that there is equity of care provision across the nation is an expressed objective. Therefore, using this NSF and other collected data at a national level will permit best practice to be identified, generated and disseminated. Manager collecting derived data about clinical and administrative activity relative to each NSF, etc., will allow progress towards the goals and aspirations of NSFs and national targets to be assessed, will identify gaps in performance to be identified, and will enable action to be taken to rectify and close those gaps; and it will assist local planning and commissioning of services.
Delivery Expectations Minimum Level to Be Achieved by December 2004 (Phase 1) Systems to be in place which collect, support and analyse nationally defined targets for NSFs and other national clinical datasets. Systems for collecting and analysing NSF and other national clinical datasets should be in place for those datasets where they have been defined prior to the end of December 2003.
FINAL 1.0a
Page 461 of 607
ICRS
Functionality to support delivery of NSF standards of care in the community (point of care) for specified early adopters.
Minimum Level to Be Achieved by December 2006 (Phase 2) NSF and national datasets will continue to be implemented according to an agreed timescale once a dataset has been defined. Extended functionality for all users.
Target for 2010 All NSF and other national care datasets shall be collected from primary sources which stem from patients, their health and Social Care professionals and their support teams using their systems at the point of care.
FINAL 1.0a
Page 462 of 607
ICRS
Overview Requirements Requirement 160.1 Overview NSFs and other similar requirements will change and be added to over time. It is expected that, when this happens, the changes will be accommodated once acceptance has been made through t e h ISB process. Required Response Each bidder shall describe its approach to supporting NSFs and other national datasets, both from the perspective of collecting the data and the analysis of it. Each bidder shall provide an overview of its approach to undertaking this work and any issues that should be considered to ensure its successful implementation.
160.2
Benefits and Outcomes The service shall support patient processes in line with NSF standards.
Each bidder shall describe how it would deliver the benefits and outcomes from this module. Each bidder shall describe its approach to integrating support for service reengineering (which NSFs and other dataset analyses stimulate) within the ICRS.
160.3
Each bidder shall describe how it will meet the minimum requirements for implementation of Phase 1 functions. Each bidder shall describe which additional functions it shall deliver during Phase 1. Each bidder shall describe the migration from where the NHS is, relative to each dataset, to its long term objective of collection of all data from primary sources.
160.4
The bidder must describe the responsibilities they would expect to be assumed by the Authority.
Detailed Requirements Requirement 160.5 Collecting the NSF and Other National Clinical Data. Required Response Identify any requirements or limitations that might apply to collection of NSF and other national clinical data in support of the national targets and
FINAL 1.0a
Page 463 of 607
ICRS
Requirement
Required Response objectives; in particular, any training issues associated with collecting and using the data for patients whose problems span NSFs.
160.5.1
The system shall collect NSF and other clinical data at source.
Each bidder shall describe how it expects the capture of NSF and other clinical datasets as part of routine clinical work. Each bidder shall describe how it would support clinical use of datasets for dayto-day (local) activity. Examples could include maintenance of evidence-based care plan templates, achievement of quality targets, etc. Each bidder shall describe how it would keep up-to-date with emerging and changing national dataset collection, clinical procedures, technologies, processes and subsequent analysis, so that its systems and procedures within the supported organisation will continue to support such national and local analytical requirements. Each bidder shall describe how its proposal will collect the specified data. Each bidder shall describe how this will be phased according to each national (NSF and other) and local target and objective.
160.5.2
The system shall use NSF data not only to support national requirements but to improve local clinical activity and planning.
160.5.3
The supplier must adhere to the requirements as specified in each of the NSFs. This, in particular, applies to national and local objectives and agreed datasets.
160.5.4
The service shall accept data in support of each of the agreed NSFs and their objectives.
160.5.5
The service shall eventually collect data from systems which support direct clinical and Social Care. It is recognised that some of the data requirements will need to be developed and calculated from such primary data. Reporting on NSF and Other National and Local Clinical Data The service must provide the appropriate reports in support of the NSF objectives.
Each bidder shall describe how its systems will seamlessly move from those which initially collect data by secondary means.
160.6
160.6.1
Each bidder shall describe how its system supports such reporting. This should include statements of timeliness and completeness for both national and local requirements.
FINAL 1.0a
Page 464 of 607
ICRS
Requirement 160.6.2 The system will provide appropriate reports for different levels of management. Using the NSF and other national and local clinical data/reports The service must stimulate and support development of care processes.
Required Response Each bidder shall describe how its system will support this and describe the levels of reporting which are necessary.
160.7
160.7.1
Each bidder shall describe what part its system will play in this development process, in particular the generic health promotion, risk detection and prevention standards for the population as well as existing patients. Special attention to tackling the disease prevalence associated with social disadvantage will be required. Each bidder shall describe what analyses and procedures it will provide to support this. Each bidder shall describe how it would see this operating and indicate the types of patient reports (e.g., to support education, risk management) and how they would be useful to patients and Clinicians. Each bidder shall describe how it will complement work being done in these areas.
160.7.2
The service must support continuing data quality improvement.
160.7.3
The service reporting.
must
support
patient
160.7.4
ICRS cannot operate in isolation. There are important other national initiatives with which the project shall keep fully aligned. In particular, close connections shall be maintained with the National Clinical Audit Support Programme which is supporting the implementation of the NSFs and their associated information strategies. Generic Functionality to Support NSF's There are generic clinical features and requirements that cross all the NSFs and will apply to other clinical areas as well. These requirements are covered by generic functionality defined as part of the ICRS. The specific application of this functionality is described below which the service shall support across all NSFs. The services shall support the management of health promotion, risk identification and risk prevention standards in the
160.8
FINAL 1.0a
Page 465 of 607
ICRS
Requirement population as they apply to all the NSFs. In particular, although not excluding other areas of functionality, the integration of eHealth components within ICRS and the use of MyhealthSpace in conjunction with ICRS shall enable this. Early diagnosis and risk reduction in patients with chronic diseases will be serviced through provision of polyclinics (DTC's and the application of eHealth requirements such as home monitoring and patient input to their health record. The service shall support these services through integration of eHealth with ICRS and supporting facilities such as polyclinics which may be within the NHS or may be private facilities contracted to provide services to the NHS. The Multi-disciplinary team (MDT) is common across all NSFs in dealing with complications of more complex chronic conditions in the community. MDT's require common functionality and the ability to access common information linking the patient at home, community based clinics and secondary and tertiary care. The ICRS shall support the MDT in providing access to common, shared information and supporting consistent working practice across disciplines.
Required Response
Specific NSF Considerations Each NSF is discussed in outline below. Use the reference sources provided above and those within each section to gain an overall picture of each NSF.
FINAL 1.0a
Page 466 of 607
ICRS
161 - MENTAL HEALTH Overview NSFs are not just about collecting data but are intended to ensure that clinical services meet the needs of their users. This part of the specification will not be a substitute for each LSP making particular reference to the specific documents available to help in satisfying mental health policy and service requirements. It is recognised that every area of specialist activity will have variations in the data it uses and the way it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activity and monitoring, is specific to mental health. The Governments vision for the care of working age adults mental health problems is embodied in the National Service Framework for mental health, which sets out specific standards for health and Social Services to improve the quality of care and reduce unacceptable variations. A key feature of the care of these patients is the co-ordination of care. Effective Care Co-ordination in Mental Health Service confirmed the Governments commitment to the Care Programme Approach (CPA) as the framework for care co-ordination and resource allocation in mental health care, and that CPA would include support for carers (the provision of written care plans being one example of this). Fundamental to mental health is the CPA. This is a cyclical patient review process that is obligatory in adult care but is also now being extended into child and adolescent care and care for the elderly. The formality and rigour implied by CPA is an appropriate setting for a good information system that assists Clinicians in the process. Over time, the focus of modern practice has been to move the care of all but the most acutely ill into the community setting; often involving a team-based approach, using care professionals and carers to support the patient.
The NSF for older people sets out standards for the care of older people. The relationship between the Single Assessment Process (SAP) and the CPA is considered in care management for older people with severe mental health problems. Other NSFs relate to social disadvantage (stress) and advanced disease. Models of care for substance misuse treatment and the childrens NSF outline proposed servi ce developments which will also have an impact on mental health. Patients may be cared for under more than one NSF - for instance an older person with mental health problems may have an assessment under the SAP, have their care co-ordinated using the CPA, and be treated under the NSF for mental health. It is important that information used within these frameworks is integrated.
FINAL 1.0a
Page 467 of 607
ICRS
Scope This section applies to the mental health NSF, i.e. to adults of working age. This does not include older people or children, to whom separate NSFs apply. The specifications do include substance misuse and forensic services, where there is a mental health component. The health and Social Care of patients with mental health problems is already or will be fully integrated across care communities. ICRS must support Health and Social Care professionals, who work together as integrated teams. In some care communities, these Healthcare professionals may be employed within a single Care Trust; in others they may remain separately employed by NHS Trusts or PCTs, and Social Services. ICRS solutions must be organisationally-independent and support alternative models, enabling all Healthcare professionals involved in integrated care processes to communicate with one another and access Patient Records and associated functionality, with appropriate access control and user authentication safeguards. The care co-ordination of patients with mental health problems, which ICRS must support, not only involves integrated care processes across health (GPs and specialist care services) and Social Care organisations, but also the co-ordination of care with other services; for example, the police and probation services and voluntary support organisations. Care is provided in a wide range of settings.Healthcare professionals must be able to access patients' records and associated functionality from all of these, including non-statutory locations and patients homes. People with mental health problems will require care for other conditions, and the specific detail of their records relating to their mental health care and status should form a component of a single logical record, which is accessible to authorised users within the care community, subject to patient consent. Mental health spans most of the generic care processes defined. There are, however, specific considerations, which include: very sensitive personal information; referral approach In childrens mental health, the ICRS must support the ability to accept family, as opposed to individual, referrals, as is the case when family therapy is being offered. Mental health services rarely conform to the model presented within 109 (eBooking), and existing procedures rely on communication between, sometimes, several individuals or teams to determine need and resource allocation; diagnostic approach This relies heavily on personal contact and conversation, rather than tests, and directly affects data capture. Exceptions include older people with undiagnosed clinical conditions (e.g., infections and metabolic disturbances which can masquerade as dementia/anxiety). In childrens mental health, diagnosis relies heavily on contact with caregivers, schools and others who may have knowledge of the child. In addition, diagnosis is multi-axial and therefore ICRS classifications should support this. Another peculiar feature of mental health services is a counter intuitive approach to diagnosis for certain patients, such as those traditionally categorised as borderline personality disordered. The very act of attributing a diagnosis can be very damaging, to the extent that further resource or
FINAL 1.0a
Page 468 of 607
ICRS
length of care spell may be extended. Whilst this can be disharmonious with management reporting needs, the benefit for the patient is clear, and should be supported; the importance of provision of education and training The provision of advice and consultation to primary healthcare workers, or workers from other agencies, is essential. This kind of clinical and non-clinical activity needs to be recorded. The provision of advice and information for patients and carers is of utmost importance. The Single Assessment Process has Publishing Information Regarding Services as its first priority. Patient and carer choice can only be facilitated fully if mental health services attend to their health education and promotion needs; the importance of understanding relationships Patient relationships between patients and other individuals such as family members, carers and other patients, must be recorded and maintained. In addition, cultural, migration and language issues may be very important to understanding the history and nature of the mental illness; the requirements of Social Care Increasingly NHS and local authority Social Care is moving to an integrated management structure for effective operation. Thus, the information systems in mental health are expected to be consolidated into a single service that must hold confidential financial information of patients necessary to implement means-tested services and the necessary functionality to support local authority reporting. Information may need to be reciprocally shared between Social Care systems, especially child protection, education and youth justice systems. Whilst integration at the point of service delivery may be achieved, the ongoing management processes and budgets remain ensconced within local authority infrastructure; well motivated patients want to know and contribute more Mental health patients are encouraged to actively participate in their own recovery. Such modern thinking requires "openness" to patient information and supports demands by patients to examine their own records. Furthermore, greater use of proposed services such as myhealthspace can engender trust and ownership of a record by a patient; Care Programme Approach & Single Assessment Process. The CPA cycle of care, in which an individual patients total requirements are reviewed periodically or after an event, implies a discipline and working style that requires a different approach from the task-oriented activities in many fields of healthcare The domains of the SAP can form the basis of the assessment of need for certain patients. The close relationship between the frameworks of CPA and SAP help to improve the experience of moving from one service area to another; a high proportion of shared clinical situations Often care is carried out on a team basis and/or in the community setting, which creates huge practical difficulties in information sharing amongst care professionals; Also, the general health of those who experience mental health problems is measurably worse than those without mental illness. Again, this serves to create complexities of multiple parallel caring situations in which a holistic understanding is essential;
FINAL 1.0a
Page 469 of 607
ICRS
assertive outreach Patients with severe symptoms but who are judged capable of sustaining an effective treatment regime in a community setting require special monitoring. Assertive outreach is a monitoring programme in which the patient's failure to achieve specific targets (such as an appointment) triggers a rapid response by care professionals;
early intervention services. Patients who have not received specialist mental health care previously, or can be supported effectively within a community setting, but require a little extra support, are effectively managed within their own homes. These teams often work with patients for a short amount of time, available around the clock on a team caseload basis. This approach demands highly reliable information delivered in a flexible manner;
risks and exceptional situations Providing information to all care professionals, carers and family about the risks associated with a patient (to themselves and/or others) is vital. Providing effective crisis and contingency plans to ensure that everyone involved, knows what to do should a crisis occur;
qualitative nature of mental health clinical care and the use of letters Mental health, unlike some other branches of medicine, is not always linear and predictable. This argues for information systems that can be less rigid in the collection of information and yet still helpful in building information and knowledge that is accurate and valuable for research;
support for carers Carers are important to the caring process and must be assessed and supported in their role. To this end, there is the need to hold substantial information, linked to the Patient Record, that can include their availability, preferences, needs, etc; and
compulsory care The Mental Health Act 1983 and the associated formalities, checks and balances, require special administrative processes; however, this extra information must be fully integrated into the patients records for effective clinical practice. In childrens mental health services other statutory frameworks must be supported, notably the Children Act 1988, the Education Act 1996 and the Crime and Disorder Act 1998.
Governance and Audit ICRS must support the selection and abstraction of data from Patient Records in order to support both operational management of services and audit, performance management and review of services. The mental health minimum dataset represents a standard dataset, the abstraction of which ICRS must support. The prime purpose of the dataset is to provide Clinicians and managers with better quality information for Clinical Audit, service planning and management. The dataset is person specific and comprises data items covering all of the care inputs received by a patient within an overall spell of care. These data items include details of clinical problems, treatments, outline aspects of Social Care and outcomes. The data items include administrative details to allow aggregate analysis by Cluster and organisation. The latest version of the mental health minimum dataset is set out at the URL, <http://www.nhsia.nhs.uk/mentalhealth/dataset>.
FINAL 1.0a
Page 470 of 607
ICRS
ICRS must support the selection and abstraction of other data from Patient Records to enable local care communities to comply with Authority requirements for aggregate information e.g. RAP, PAF etc . ICRS must support the monitoring of quality targets for the processes involved in delivering mental health services; particularly those associated with the elapsed times between reviews where the patients care is coordinated in line with CPA. ICRS must also support the definition, selection and abstraction of locally-defined datasets. Mental Health Act 1983 (the Mental Health Act) or (the Act) The service shall support the Mental Health Act processes, including those described below. Functionality should be available for a variety of care scenarios/locations. Decision support should be available to ensure correct application of the Act. Workflow and diary principles should be available to ensure time-critical events are flagged, such as link events, throughout a period of detention; and alerts regarding elapse of time periods should be present. Examples are listed where appropriate. Classification and access of staff to complete processes within the Act should be in place; i.e., a practitioner approved under s. 12 of the Act. Administration of the Act shall be supported; that is, the production and completion of the necessary forms as detailed by delegated legislation is required. Compilation of legal documentation following pre-determined protocols is a pre-requisite. Application of the Mental Health Act The service shall support the terminology used within the Act e.g., a "patient" is described under Section 145(1) (Interpretation) of the Act, whereas a Patient is not. Synonyms should be available for use throughout a system to reflect dissimilar working practices, but in the application of the Mental Health Act only section 145 terms will suffice. Compulsory Admission to Hospital and Guardianship, Section 2-34 The service shall support the admission procedure, ensuring grounds for detention are satisfied. Correct administration of the Act shall be supported. The production of forms and details of dates and times contained therein should trigger events, such as the patient being given rights, review events or further applications, and support the booking of activity into specific practitioners diaries. As part of the administration of the Act, the production and recording/storage of reports (including assessments which do not conclude with an admission under the Act, and the Approved Social Worker assessment), should enable reporting required of organisations, such as the KP90 return. The service shall also support Mental Health Act activity carried out by persons not associated to the patient in a professional capacity; i.e., the "Nearest Relative" (section 26). Patients Concerned in Criminal Proceedings or Under Sentence, Section 35-55 Partnership working with courts and other criminal justice departments is of paramount importance for this user group, so interfacing with these agencies is desirable. The overall functionality required is similar to that for patients not concerned in criminal proceedings. Some exceptions to this statement would be: this user group does not require a second medical opinion to be from a different organisation; and section 17 leave, in some cases, needs to be granted by the Home Office after a request from the RMO.
FINAL 1.0a
Page 471 of 607
ICRS
Consent to Treatment, Sections 56-64 The functionality required to support the following activity is in essence the same as care coordination/care management. Eligibility, planning and review (under sections 56, 59, 61and 62 of the Act) of treatments provided, require the same support. Treatments which require either consent and a second opinion (section 57 of the Act), or a second opinion (section 58 of the Act) shall require support, as far as practicable, to schedule appointments for approved practitioners. The remainder of the sections pertain to the provisions and classification of treatments under the Act, and the withdrawal of consent. The procedures detailed may be supported by way of alerts - for treatments requiring second opinions, for example - or by beginning a chain of events to support this clinical activity, such as the support for scheduling of a second opinion practitioner to complete the necessary assessment. Mental Health Review Tribunals (MHRT), Sections 65-79 The Act describes the patients rights to make an application to the MHRT. Support for this process should assist Mental Health Act administrators in scheduling a date for a tribunal. Also required is support to determine when persons are available to be present and support in the collection of information in support of the application. Activities that may arise from the MHRT, such as discharge from a section, have implications for aftercare (section 117 of the Act) and must be supported. Removal and Return of Patients Within United Kingdom, etc., Sections 80-92 The functionality required to support this activity is the compilation of legal documentation to support the removal or return of patients. Management of Property and Affairs of Patients, Sections 93-(see 113/114) The functionality required to support this activity is largely administrative; i.e., the possible compilation or storage of legal documentation to support the management of a patients property and affairs as defined within the act. Miscellaneous Functions of Local Authorities and the Secretary of State, Sections 114-125 Function and appointment of ASWs under the Act are covered (by sections 114 and 115 of the Act). Welfare of patients and provision of aftercare arrangements after a period of detention for treatment (section 117 of the Act) shall be supported, including the provision of an aftercare plan and appropriate documentation. Aftercare and the Care Programme Approach are closely linked. Miscellaneous and Supplementary, Sections 131-149 These sections cover details as varied as Informal Admission of Patients (section 131 of the Act) and their rights under the Act and procedures pertaining to mentally disordered persons found in a public place (section 136 of the Act). Functionality should extend to the storage of legal papers regarding actions taken under the Act. Revisions to the Mental Health Act, Including Minor Revisions or Major Changes The service shall support any changes to the Mental Health Act. Whilst there is no firm decision to implement proposed changes to the current Mental Health Act, it should be expected that changes to
FINAL 1.0a
Page 472 of 607
ICRS
the Act will occur in the future. Therefore, systems shall be able to support revisions in the detail of the Act, based upon similar processes. Substance Misuse Services for people who misuse substances (drugs, alcohol, etc.) can be independent services but are generally placed within adult mental health service organisations. Such services provide a range of community services to people who have a physical substance dependence. Services offered include assessment and care management, detoxification, counselling, substitute prescribing, provision of residential/day/domiciliary care and needle/syringe exchange. Also included are Hepatitis B and C testing and treatment with pre- and post-testing counselling. Types of staff working in this are community nurses, social workers, doctors, administrative staff and support workers. These staff may be supported by specialists, such as counsellors and substance misuse workers. In general the requirements will include the need to: support the range of forms that are used within the substance misuse setting; interface with existing prescribing services; support needle exchange, which requires keeping records of needles exchanged by identifying initials and code numbers; support HIV and hepatitis testing; and provide appropriate reports for drug actions teams, the national treatment agency and the national drugs treatment monitoring service.
The requirements for mental health will be met through the application of the generic functions specified in Modules 101 - User Tools to Module 125 Surgical Interventions. It is not the intention that any separate systems would be supplied to meet the needs of any condition-specific area. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of mental health services and their practice. In each case, reference has been made to relevant generic modules.
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide
161.1
GP assessment of Assessing the needs of patient / clients (service users) and carers The service shall provide all care professionals in relevant Social Care departments, Primary Care, Acute Care, and secondary and tertiary mental health units ('care professionals) with the patients care history, identifying current and previous episodes of mental health problems managed within primary care and/or involving specialist mental health services, care plans, treatment / 104 Assessment 105 Integrated Care Pathways and Care Planning 113 Prescribing and Pharmacy 119 Social Care
161.1.1
FINAL 1.0a
Page 473 of 607
ICRS
medication used, record of compulsory care, and recorded outcomes. 161.1.2 The service shall provide decision support / assessment tools for use by care professionals (where they exist) to assess the nature and severity of the problem. All care professionals shall be able to access current standards and procedures on the service to guide their choice of medication care provision including and/or use of services. The service shall support GPs in providing information and advice to the patient on their problem and details of services available (e.g. self-help groups, help-lines, support for family and carers, as well as information on medication and adverse effects, etc.) The service shall support GPs in scheduling regular follow-up appointments to review the patients condition. 112 Decision Support
161.1.3
112 Decision Support
161.1.4
105 Integrated Care Pathways and Care Planning 106 Clinical Documentation
161.1.5
108 Scheduling 109 eBooking 119 Social Care
161.1.6
The service shall support GPs in assessing and supporting patient carers, in keeping with NSF Standard 6.
104 Assessment 105 Integrated Care Pathways and Care Planning
161.2
Providing care in a Primary Care setting The service shall support the prescription of medications, including expert decision support and best practice guidelines. The service shall support referrals for primary care based counselling, psychological therapies, occupational and social care (and the subsequent scheduling of resources and booking of appointments). 113 Prescribing and Pharmacy 112 - Decision Support 106 Clinical Documentation 108 Scheduling 109 eBooking 119 Social Care
161.2.1
161.2.2
FINAL 1.0a
Page 474 of 607
ICRS
161.2.3
The service shall record the outcome of care inputs and medication provided in a primary care setting, using standard national measures when available (including user-defined). Referring patient / clients for specialist assessment and/or treatment The service shall support care professionals in requesting specialist mental health services. They shall be able to search and retrieve information from service directories on-line, with point and click web style navigation. This may involve automated dialogue with mental health service co-ordinators prior to booking actual appointments for patients, and where necessary supporting professionals to arrange/book transport to attend the appointment. The service shall support the use of protocols to guide care professionals in making referrals (in line with NSF proposals covering specific mental health problems (e.g. dementia and schizophrenia)) including prompting for the information required to support the referral and making this information available to the recipient of the referral. This shall include, for example, patient identifiers and personal characteristics, a summary of the patients case history, the nature of the problem and the degree of urgency, risk, severity, chronicity, past treatment and its outcome, and details of current non-mental health information.
104 Assessment 113 Prescribing and Pharmacy 119 Social Care
161.3
161.3.1
109 eBooking 106 Clinical Documentation
161.3.2
106 Clinical Documentation 112 Decision Support
161.3.3
The estimated time for a response / appointment shall be recorded and, if that time has elapsed, the service shall prompt the primary care professional that no response has been received. Providing continuity in a patient /
107 Care Management
161.4
FINAL 1.0a
Page 475 of 607
ICRS
clients care 161.4.1 The service shall support care professionals, in all organisational contexts, in participating in the CPA process, including reviews. This will include: receiving notification; scheduling participation; attendance or 107 Care Management 108 Scheduling on care plans and 109 eBooking 123 eHealth and Clinical Development and Clinical Development 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation
reviewing care records; commenting outcomes;
remote participation (e.g. via voice or video conferencing); and viewing documents received from external sources (e.g. scanned letters).
161.4.2
The service shall notify care professionals of significant changes in a patients care plan including emergency presentations, changes in legal status, changes in care plan or programme, assessed risks and discharge; and provide all authorised care professionals with context specific access to details of assessments, care plans, crisis plans, care inputs received, medication etc. These details should be accessible via the Personal Spine Information Services.
104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 770 Clinical Communications
161.5 161.5.1
Managing referrals Requests may be received from patient themselves, family, carers or neighbours, GPs, social workers, NHS Direct, other healthcare professionals, police etc. Currently they may be received face to face, by telephone, by fax, by email/message or by letter. The service shall enable all requests to be made 106 Clinical Documentation
FINAL 1.0a
Page 476 of 607
ICRS
electronically. 161.5.2 The service shall support the receipt of referrals, where necessary capturing or providing access to basic details about the potential patient and the perceived problems leading to the request, using prompts for telephone contact and electronic formats if available. Support is required for the capture of both coded information and structured text. The support provided should minimise the time and effort required to capture this information accurately, and should be supported by prompts and alerts (including identified risks), pick lists, the retrieval of reference information to help accurately populate certain types of information from partial completion, e.g. address details. The service shall support the notification of the request to other care professionals and nearest relative (Mental Health Act) currently involved in the care of the patient subject to patients consent. The service shall support care professionals in applying criteria, which may be used to determine whether an assessment is required, and what priority to attach to its completion. Allocation for assessment may be referred to locally as triage or screening. The process should culminate in a decision on how services are planned to address the needs communicated in the referral. This process should be carried out by identified professionals, who hold interim responsibility for the case and, using referral information in discussion or protocols, form a preliminary plan. This may involve a second assessment, nonacceptance of the referral, or referral to a third agency or team. 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 112 Decision Support
161.5.3
106 Clinical Documentation 119 Social Care
161.5.4
105 Integrated Care Pathways and Care Planning 112 Decision Support 119 Social Care
FINAL 1.0a
Page 477 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 104 Assessment 105 Integrated Care Pathways and Care Planning 119 Social Care
161.5.5
The service shall provide care professionals with access to comprehensive patient records, including up to date risk assessments, care plans and crisis plans in a range of care settings, and under both planned and emergency circumstances Where additional information is required about the request and/or the patient the service shall support the care professional in requesting additional information from other care professionals and the original requester. Case Allocation and Management The service shall support the: allocation of requests to care professionals as coordinators, which may involve application of rules to indicate team members with capacity and appropriate skills to take responsibility. Links to caseload weighting and diary functions should indicate availability and ability to proceed within time frames based upon priority. The service shall support notification of an allocation to a team member, with target dates for completion of assessments etc., based on standard protocols; and reallocation of responsibilities either on a temporary basis (to ensure targets achieved for individual cases where there are planned absences) or a permanent basis.
161.5.6
161.6 161.6.1
101 User Tools 105 Integrated Care Pathways and Care Planning 107 Care Management 112 Decision Support 119 Social Care
161.6.2
The service shall support automatic monitoring of the achievement of target completion dates for the assessment and care of patients by an individual team member and team manager, indicating, for example, assessments due to be completed within a specified number of days and assessments overdue etc. It should also support aggregate monitoring of caseloads (volumes, complexity etc.),
101 User Tools 105 Integrated Care Pathways and Care Planning 124 Information for Secondary Clinical Purposes 119 Social Care
FINAL 1.0a
Page 478 of 607
ICRS
performance in meeting targets etc. 161.7 161.7.1 Assessing care needs The service shall support the scheduling and booking of assessment appointments and enable care professionals and others to manage adjustments, cancellations and further bookings. 105 Integrated Care Pathways and Care Planning 108 Scheduling 109 eBooking 119 Social Care 161.7.2 The service shall prompt and record securing of the patients or a carers consent for the assessment and for the use and sharing of information. The service shall provide mental health professionals with the patients care history, identifying current and previous episodes of mental health problems managed within Primary Care and/or involving specialist mental health services, care plans, treatment / medication used and rec orded outcomes. (see #161.1) Mental health professionals shall be able to access current standards and procedures on the service to guide their choice of medication and/or use of services. The service shall support mental health professionals in providing information and advice to the patient on their problem and details of services available (e.g. self-help groups, help-lines etc.). The service shall support mental health professionals in scheduling regular followup appointments to review the patients condition. 104 Assessment
161.7.3
104 Assessment 105 Integrated Care Pathways and Care Planning 113 Prescribing and Pharmacy 119 Social Care
161.7.4
161.7.5
161.7.6
161.7.7
The service shall support mental health professionals in assessing and supporting the patients carers, including provision of
104 Assessment
FINAL 1.0a
Page 479 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Care pathways 119 Social Care
information such as printable leaflets explaining the condition, problems and needs and the proposed management thereof. 161.7.8 The service shall support the capture / recording of additional patient details required to assess a patients care needs. This may involve: receiving responses to requests for additional information; and capturing the outcomes of interviews/discussions with patients.
104 Assessment
As above, support is required for the capture of both codified information and structured text, which forms an integral of part of the patients record. The service shall enable care professionals to record levels of risk of self-harm or harm to others and dependency. The service shall use prompts, simple recording of scores (using a range of input methods) and through warnings for possible inconsistencies or errors. 161.7.9 The service shall support mental health professionals in carrying out risk assessments, and the facility to record and make clear alerts. The service shall support care coordinators in requesting further detailed assessments or specialist assessment. 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care 161.7.11 The service shall allow access to documents covering previous assessments. It should be possible to access these from within a structured patient record, with the ability to easily retrieve specific sections within documents. 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation
161.7.10
FINAL 1.0a
Page 480 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 104 Assessment 112 Decision Support 119 Social Care
161.7.12
The service shall support care professionals in applying systematic assessment tools, which may comprise different types of measurement scales. Assessment is a generic process, which is common to the planning of care for all patients in various settings. The assessment tools (scales and measurements and the characteristics of patients or responses to problems that are measured or assessed) used will differ according to the patients problems or conditions. Changes in the values measured or assessed using these tools are important in determining the effectiveness of both the care of individual patient, but also when abstracted and analysed for classes of patients in determining the overall effectiveness of the care provided. Across the care communities within any geographical area a number of different assessment tools may be used. Solutions should be capable of supporting all of these assessment tools. The service shall support the use of a range of assessment tools. The service shall provide support for the capture of the outcome of the assessment using both a standard consistent terminology and classification, which is codified and as a text description. Outcome measures of HoNOS, HoNOS65+, HoNOSCA, HoNOS-Secure, HoNOS-LD, HoNOS-ABI shall be supported.
161.7.13
Notification of outcomes of the assessment shall be compiled and distributed by the service to other professionals and agencies that have been involved in joint or complex assessments, and as appropriate the nearest relative (Mental Health Act). The details should be accessible via the Personal Spine Information Service. The service shall support monitoring of the time taken to complete assessments
104 Assessment 106 Clinical Documentation 119 Social Care 770 Clinical Communications
161.7.14
101 User Tools
FINAL 1.0a
Page 481 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 124 Information for Secondary Clinical Purposes
(from the initial referral, and from the request for assessment to be undertaken) and compare these actual elapse times with target or standard times. These may be general or specific applying to patients with particular demographic characteristics, domestic circumstances, level of risk and CPA level. The service shall alert care professionals of variations in actual and expected elapse times. 161.8 161.8.1 Developing a care plan The service shall support development of care plans, which: the
105 Integrated Care Pathways and Care Planning 119 Social Care 123 eHealth and Clinical Development and Clinical Development
are multi disciplinary and may involve care inputs from several different agencies within and external to the statutory arena, (e.g. independent sector care provider organisations); have both overall objectives and targets, and specific ones relating to the inputs of specific care professionals; have milestones and review dates; and; may comprise housing, education, employment and welfare components, as well as health and social care inputs; have the ability for data to be exported or displayed in a number of user-defined formats to meet local practice, terminology and expectations.
The format of the care plan should be: Aims/objectives/expected outcomes Complete list of interventions, packages of care, and integrated care pathways Crisis and contingency plans Contacts (professionals & units, including out of hours support). Consent & agreement of the patient & carer.
FINAL 1.0a
Page 482 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Integrated Care Pathways and Care Planning 119 Social Care
161.8.2
The service shall support the development of crisis and contingency plans for patients with severe mental health problems. These plans will detail the care inputs required when a patient presents in emergency circumstances, including details of care professionals and nearest relative (Mental Health Act) to contact. To support care professionals in developing care plans, the service shall: provide care professionals with access to guidelines and protocols to identify possible care plan components, including the intelligent selection/proposal of Integrated Care Pathways, based upon assessed needs/issues/risks/problems; and
161.8.3
105 Integrated Care Pathways and Care Planning 109 eBooking 119 Social Care
161.8.4
provide access to service directories covering possible service providers range of services, capacity, costs, and performance quality indicators as part of care package commissioning activity. Directories of Integrated Care Pathways should be available for interrogation for appropriateness as elements in a care plan. The service shall allow care professionals to involve patients and their carers(including the nearest relative (Mental Health Act)) in the process of developing the care plan, by providing easy to use ways of accessing details, including printed copies. The service shall allow patients and carers comments, preferences and their agreement to the plan (or dissent) to be recorded. Furthermore, a carers care plan should be constructed after assessment to include: Information regarding the needs of the patient they are caring for, (e.g. information that will help them carry out their caring duties); Interventions to meet carers' mental
105 Integrated Care Pathways and Care Planning 119 Social Care
FINAL 1.0a
Page 483 of 607
ICRS
161.8.5
and physical and social care needs; Crisis & contingency plans; and Information regarding appeals, complaints, liaison, and advocacy services. The service shall support the automatic application of rules / criteria for determining the financial contributions that a patient may be required to make, and the production of alternative schedules of contributions relating to possible care plans (including financial implications of section 117 Mental Health Act discharge and aftercare support where applicable). The service shall support the evaluation of the alternative care plans, including: producing alternative overall costs for the complete plan in case of plans with fixed duration, or for comparable time periods for ongoing plans; and producing scores for alternative care plans, the likelihood of achieving objectives and for associated risks.
105 Integrated Care Pathways and Care Planning 112 Decision Support 119 Social Care
161.8.6
161.8.7
The service shall: support care professionals and managers in assessing the financial implications of care plans; enable details of the ongoing financial implications and affordability of a care plan to be calculated; allow aggregate analysis of commitments implied by commissioned care plans, and comparisons with budgets (at team, locality level etc.) to give outturn forecasts of over/ under spend; and allow professionals to compare financial and outcome measures, analysed within groupings defined by age, sex, ethnicity, condition, intervention and service boundary.
161.8.8
The service shall support the use of electronic methods for the authorisation of
105 Integrated Care Pathways and Care
FINAL 1.0a
Page 484 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide Planning
care plans and notes. This requires strong user and patient authentication, and detailed audit trails. 161.8.9 The service shall support care professionals in notifying patients (and carers / third parties) of the proposed care plan and assessments of the financial contributions required.
105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care
161.9
Requesting or commissioning services as part of a care plan The service shall support care professionals in requesting / ordering the planned care by: providing service suppliers with access to necessary information on the patients relevant care history, the level of urgency, any identified risks, the problem and the services required etc. This should include details of who to contact for access/authorisation in order to access information not supplied initially; recording the request and the date it was sent, and the expected date of a response to enable care professionals to monitor the provision of these requested services; prompting care professionals when a response to a request is overdue and providing the relevant contact details to enable the care professional to follow up the delay; notifying other care professionals of the request for services that have been made; providing integration with local authority financial systems as the originator of payments for services. 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 109 eBooking 110 Requesting and Order Communications 111 Results Reporting 117 Financial Providers 119 Social Care 780 Interfaces Payments to Service
161.9.1
161.10 161.10.1
Providing Care The service shall enable all care professionals to access and update 104 Assessment
FINAL 1.0a
Page 485 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care
details of patients records (capturing details of activities / actions undertaken (dates, durations etc.) and the outcomes of care and progress in achieving care aims, including revised assessments) at all locations at which care is being provided. Day to day contacts should be recorded within the clinical noting facility. This activity can be entered by a range of professionals, and their contact reason/duration/outcomes should be available for management reporting purposes. The facility shall be provided for notes made by students or untrained staff to be authenticated. This function should also link into crisis and contingency plan options, as monitoring of ongoing care often demands reappraisal of risk, crisis events and the efficacy of the plan to deliver the expected care outcomes. Some care may be provided remotely by video conferencing with the patient in the GP surgery, CMHT base or other setting, or by virtual visiting in the patients home. Patients physiological signs and daily living activity may be monitored remotely. 161.10.2 The service shall support care professionals through warnings and alerts for staff visiting, for example highlighting if the patient or carer is known to be confused, violent or may have an adverse reaction to a particular drug or situation, own violent pets or have dependants whose needs should be considered. The service shall support authorised care professionals in the prescribing and administering of pharmaceutical products including controlled drugs. The service shall provide support for care professionals in requesting or ordering further care inputs, equipment or
112 Decision Support 119 Social Care
161.10.3
113 Prescribing and Pharmacy
161.10.4
108 Scheduling 109 eBooking
FINAL 1.0a
Page 486 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 110 Requesting and Order Communications 111 Results Reporting 119 Social Care
transport.
161.10.5
The service shall support scheduling and re-scheduling of care inputs, based upon the patients requirements and the resources available using agreed rules and protocols. In supporting the scheduling of care, the service shall incorporate rules relating to and/ or provide care professionals with access to details of: particular patient preferences such as culture, age or sex of staff providing care; staff availability (i.e. working days and hours, holidays arranged, training arranged, current commitments); available staff skills and attributes such as age, sex, location and culture; geographic locality information such as travel times; and, estimated time taken for set tasks (e.g. administering medication). include the
101 - User Tools 108 Scheduling 109 eBooking 119 Social Care
161.10.6
This support should production of staff rotas.
161.11 161.11.1
Reviewing a care plan The service shall support activities for ensuring that patients are monitored and their care is reviewed within an agreed period; this includes assertive outreach services and crisis teams. This could be done by virtual visiting and/or remote monitoring. 104 Assessment 105 Integrated Care Pathways and Care Planning 123 eHealth and Clinical Development and Clinical Development
161.11.2
The service shall support review processes for the re-assessment of needs
104 Assessment
FINAL 1.0a
Page 487 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Integrated Care Pathways and Care Planning 119 Social Care
and risks and the amendment of care plans, including both major plan reviews and minor amendments such as change of medication dosage or telephone numbers through: prompting that a review is required as specified by original care plan; identifying the occurrence of an event that should trigger a review (such as not attending a regular clinic and missing necessary medication); and
The use of variance within Integrated Care Pathways may indicate that a review is necessary. A systematic review shall be supported and shall include the following elements: Reassessment of the patient Assessment of the plan against its outcomes Assessment of delivered against planned care. care
161.11.3
The service shall support carecoordinators in scheduling both planned and unplanned care, for example: notifying care professionals involved in complex assessments of the timing of and need for review; scheduling the required actions and appointments, including any review meetings; and, following up outstanding actions etc.
105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 108 Scheduling 109 eBooking 119 Social Care
161.11.4
The service shall support care professionals in comparing the care actually delivered to the care plan / pathway, in monitoring the current status of requests for services made, in assessing the quality of care provided, through outcomes and patients preferences.
105 Integrated Care Pathways and Care Planning 124 Information for Secondary Clinical Purposes
FINAL 1.0a
Page 488 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care
161.11.5
The service shall support (as above) the review of the carers care.
161.12
Assessing the need for the use of compulsory treatment The service shall support care professionals in undertaking this specific instance of assessment of a patients needs. The assessment will in particular consider the risks of self harm and harm to others, self neglect or vulnerability to exploitation. The presence of mental illness also needs to be established, as does the likelihood of achieving concordance with an alternative plan that does not require compulsory powers. Risks which may arise out of a patient not consenting to recommended treatment or missing essential care events or treatments (failure to take medication etc.) also need to be established. The service shall provide access to the patients care history and in particular details of any failures to receive essential treatment and the associated risks. The instigation of an assessment can be progressed by a GP, consultant, social worker or the police/others. The convening of the assessment should be directed via workflow functionality to an Approved Social Worker service or similar locally agreed protocol. 104 Assessment 105 Integrated Care Pathways and Care Planning 108 Scheduling 780 Interfaces
161.12.1
161.12.2
A number of assessments need to occur usually two medical recommendations (one from a Section 12 approved doctor, the other from a doctor who has previous knowledge of the patient). An Approved Social Worker will assess all aspects of the case including s ocial circumstances, contact the nearest relative, etc. Finally the application itself may be made by the nearest relative or ASW. The service shall accommodate multiple assessments and
104 Assessment 112 Decision Support 119 Social Care
FINAL 1.0a
Page 489 of 607
ICRS
inputs from a variety of sources, and provide details of standards and procedures to follow in order to comply with the Mental Health Act and/or guidelines. 161.12.3 These assessments may be undertaken in emergency circumstances. The service shall support care professionals undertaking assessments in settings such as the patients home, police station, A&E department etc. The service shall support the notification to other care professionals, carers, legal representatives and other relevant parties of the assessment and outcome. That includes that roles of the Approved Social Worker and nearest relative (Mental Health Act). Making an application for the use of compulsory treatment The service shall support the application for the use of compulsory powers, following a preliminary assessment of the problems and conditions of a patient and risks associated with these. This application for compulsory powers requires support for: extraction and assembly of information from Patient Records to populate application documents; electronic dispatch of documents over secure communications infrastructure; and capture of completion documents. dates and of application, dispatch of 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 104 Assessment 105 Integrated Care Pathways and Care Planning 119 Social Care 104 Assessment
161.12.4
104 Assessment 106 Clinical Documentation
161.13
161.13.1
161.13.2
The service shall support the notification of application to patients, carers, nearest relative (Mental Health Act) and legal representatives and recording of receipt/acknowledgement of the notification and details concerning
FINAL 1.0a
Page 490 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 119 Social Care
consent. 161.14 Preparing the case for the use of compulsory powers The service shall provide access to information required for care professionals to prepare evidence in support of the application at court hearings or tribunals. The service shall also support patients and carers within this activity. Support is required to engage patient advice and liaison services, or other non-statutory liaison or advocate services to act on/in concordance with, the patient and carer. Assuming the correct permissions and consents are obtained, information regarding a course of action should be made available to these individuals, so that they can best serve the patient and carer. 161.14.2 The service shall support care professionals in scheduling their attendance at tribunal and court hearings, including prompts and reminders. The service shall support the patient in this process. Receiving response to an application for the use of compulsory powers When care and treatment orders (from Mental Health Tribunal / court) are received, the service shall enable these to be recorded within patient / client records. Following receipt of response, the service shall proactively prompt actions based on the content of the response and the standards and procedures in place. This should include notifying patients, carers and legal representatives, as well as care professionals and any liaison or advocate involved in the provision of care to the patient / client.
161.14.1
101 User Tools 119 Social Care
161.14.3
105 Integrated Care Pathways and Care Planning
161.15
161.15.1
105 Integrated Care Pathways and Care Planning
161.15.2
105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 112 Decision Support 119 Social Care
FINAL 1.0a
Page 491 of 607
ICRS
161.16 161.16.1
Receive conditional discharge details When details of patients discharged conditionally are received by the care team, the service shall support the inclusion of these details within patient records, the notification of the details to relevant parties, and proactively prompt actions based on the conditions and the standards and procedures in place including any planned/statutory reviews or CPA processes. Furthermore the system should warn/prompt/bar discharge if conditional elements are not in place (e.g. secure housing, financial aid, community support). Monitor the fulfilment of conditional discharge details The service shall enable care professionals to review the fulfilment of conditions. The service shall automatically prompt the care professional when the patient has defaulted on one of the conditions and then notify other parties immediately of the default e.g. Approved Social Worker, nearest relative (Mental Health Act), police, courts, home office etc. This functionality should extend to drug treatment and testing orders in use by drug action teams. Apply for an extension for the use of compulsory treatment The service shall support care professionals in seeking authorisation for extended use of compulsory powers (or reapplying for care and treatment orders). Care professionals should be alerted that an initial period of assessment and treatment is due to expire and authorisation is required to extend compulsory treatment. The remaining functionality required is similar to that required for initial applications outlined above. 105 Integrated Care Pathways and Care Planning 108 Scheduling 119 Social Care 780 Interfaces 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 112 Decision Support 119 Social Care
161.17
161.17.1
161.18
161.18.1
FINAL 1.0a
Page 492 of 607
ICRS
Applications for extensions of prescriptions of dangerous treatments like ECT, should also be supported, ensuring that the procedures for booking an appropriate review, and Mental Health Act commission second opinion approved doctor, should be facilitated. 161.19 Responding to an appeal under the Mental Health Act Patient and/or their nearest relative (Mental Health Act) may appeal against the use of compulsory powers. The service shall provide similar functionality to that detailed in: Making an application for the use of compulsory treatment; and Preparing the case for the use of compulsory treatment. 105 - Integrated Care Pathways and Care Planning 108 - Scheduling 119 Social Care 780 - Interfaces
161.19.1
The service shall provide functionality to support activities: Convening a Mental managers meeting; Health Act
Convening a Mental Health Review Tribunal.
161.20 161.20.1
Emergency presentation The service shall support care professionals dealing with a presentation of a patient at a care or other location in emergency circumstances. The location may typically be an out of hours emergency clinic or an accident and emergency unit. It must also support an emergency presentation of patients with severe mental health problems via the criminal justice system. The service shall provide care professionals with access to Patient Records and, in particular, details of the patients care history, identified risks and crisis plan and details of current and past 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 119 Social Care 123 eHealth and Clinical Development and Clinical Development
FINAL 1.0a
Page 493 of 607
ICRS
compulsory care. Access to the patient may be by video conferencing (e.g. in prison or police station). 161.21 161.21.1 Implement crisis care plan The service shall provide access to crisis plans that cover known situations. The service shall support care professionals in the implementation of the actions outlined in the crisis plan. For example, requesting other services or applying for compulsory powers. The service shall support care professionals in requesting care inputs required by the crisis plan, (e.g. emergency inpatient care) by providing access to service directories and associated resource schedules covering possible service providers range of services, capacity (bed availability) and quality indicators. (Links to 161.8) The service shall support the notification of the emergency incident to the other care professional involved in this patients care and any changes to care plans, subject to consent to sharing this information. This will enable care professionals to suspend, reschedule or cancel existing planned inputs. Provide emergency care The service shall provide the selected emergency service provider with access to the patients crisis, objectives, care inputs and identified risks and previous care history including information on current or past compulsory care. The service shall support care professionals in making decisions on the appropriate treatment and whether compulsory powers are required and/or appropriate by providing access to 105 Integrated Care Pathways and Care Planning 112 Decision Support 119 Social Care 105 Integrated Care Pathways and Care Planning 119 Social Care
161.21.2
161.21.3
161.22 161.22.1
FINAL 1.0a
Page 494 of 607
ICRS
appropriate guidelines and protocols.
Further, more detailed, specifications can be found in Mental Health ICRS Requirements: Descriptive Statement of Clinical Process and Need, (NHSIA) July 2003: www.nhsia.nhs.uk/mentalhealth/mhis/pages/documents/mhICRSreq.pdf
FINAL 1.0a
Page 495 of 607
ICRS
162 - DIABETES Overview NSFs are not just about collecting data, and this part of the specification will not be a substitute for each LSP making particular reference to the specific documents available to help in satisfying diabetes policy and service requirements. It is recognised that every area of specialist activity will have variations in the data it uses and the way that it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activ and monitoring, is specific to the care of patients with diabetes. ity In support of the steps proposed in the delivery strategy for the diabetes NSF, ICRS will provide analyses to: monitor the creation and maintenance of diabetic networks; review of local implementation arrangements; audit local and national achievements; and support local skills development.
The generic functional requirements for care for patients (including those associated with diabetes) are covered in Modules 102-117. Scope The health and Social Care of patients with diabetic problems is already or will be fully integrated across care communities. ICRS must support health and Social Care professionals, who work together as integrated teams. In some care communities, these care professionals may be employed within a single Care Trust; in others, they may remain separately employed by NHS Trusts, PCTs or Social Services. ICRS solutions must be organisationally independent and support alternative models, enabling all care professionals involved in integrated care processes to communicate with one another and access Patient Records and associated functionality, with appropriate access control and user authentication safeguards. Nationally, the prevalence of diabetes is expected to double over the next 10 years due to increased obesity and an ageing population. The provision of effective systems support for these care components will be essential in enabling local care communities to meet the care needs of increasing numbers of people with diabetes. Currently, many people with diabetes have their routine care within Secondary Care. A functional ICRS enabling e-health, including personal telemonitoring, will transfer care to the community, supporting lifestyle change and risk prevention and directly addressing the causes of the increase in diabetes. Secondary Care will provide specialist care for people with complications or unstable or complex conditions. It is this changing emphasis which ICRS must support. Governance and Audit ICRS must support the selection and abstraction of data from Patient Records in order to support both operational management of services and audit, performance management and review of services. Clinical governance and audit of processes and outcomes will take place within individual service providers, with comparisons at practice, PCT, care community, SHA and national levels. Audit will also take place of multi-disciplinary care pathways and processes, which span individual service providers within a care community.
FINAL 1.0a
Page 496 of 607
ICRS
Services must enable data to be abstracted from the individual Patient Records supporting direct care and analysed at all of these levels. ICRS should enable information to be abstracted from individual Patient Records to enable audit of each service components own population of people with diabetes; i.e., by individual practices, departments within Trusts and specialist services. ICRS should enable data to be abstracted assembled on a pan-community basis to enable clinical governance and audit at PCT level. Systems should be able to maintain and manage data, enable analysis, and have the functionality to present and deliver information to individuals within organisations with a clinical governance role and to feed back information to Clinicians about their own services. Access to comparative information is needed such as national and other relevant baseline trends and rates, to enable benchmarking of results. Systems should support audit of both processes and outcomes. Services must also enable data to be abstracted, linked with demographic and other data and analysed to enable overall services to be planned at care community level, identifying the prevalence of diabetes in different groups within local populations and the incidence of particular care events. Information is required at care community level to support needs assessment and service planning. Systems must enable information to be abstracted from operational Patient Records to enable the aggregation and analysis of this data to provide information by population group, practice, age, area, severity, interventions, outcomes, etc. Information may also need to cover the population covered by adjoining health communities, which span more than one SHA. ICRS needs to support patient and health professional training by audit data and as a conduit to information, education (on- and off-line). Services must support the managers and individual care professionals involved in the provision of individual care components within the pathway of care for people with diabetes in managing caseloads. Information on caseloads for different clinical teams or service components (e.g., podiatry, retinopathy) is required in order to enable proactive service management, resource and manpower planning. For some services such as podiatry, it is important to recognise that information is required across all the populations for which the service is provided, i.e., across the PCT, or community wide, and covering the entire service, not solely the diabetes management component. The diabetes dataset is under development. It will eventually represent a standard dataset, whose abstraction ICRS must support now and in the future. The prime purpose of the dataset is to provide patient, carers, Clinicians and managers with better quality information for Clinical Audit, and service planning and management. The dataset is person specific and comprises data items covering all of the care inputs received by a patient within their overall care. The latest version of the diabetes dataset is set out at the URL, <http://www.doh.gov.uk/nsf/diabetes/ch1/standardstable.htm>. The Diabetes User Dataset (DUD) is the first of a number of component elements of the diabetes dataset which will facilitate consistent data collection at the point of care, and will be shared electronically between organisations and healthcare professionals. A patient user view (paper and/or electronic) will be shared with the person with diabetes. The DUD aims to include all the basic data needed by patients to inform them about the progress of their condition and support selfmanagement. It allows patients to understand and take informed control of their care by summarising: contact details of care providers; health issues and their treatment; results and implications of regular preventive care clinical and laboratory reviews; forthcoming treatment targets; and scheduled review
FINAL 1.0a
Page 497 of 607
ICRS
dates. The dataset does not set out to describe how the data should be displayed or printed for the user, or how much of it should be output in either form. The DUD is only one view of the dataset other views will focus on the healthcare providers perspective or that of the service delivery manager. Extension datasets will present the data generated by specialist services, such as eye, foot, pregnancy, renal or cardiovascular care. ICRS must also support the definition, selection and abstraction of locally defined datasets. The requirements for diabetes will be met through the application of the generic functions specified in modules 101-125. It is not the intention that any separate systems would be supplied to meet the needs of any condition-specific area. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of diabetes. In each case, reference has been made to relevant generic modules.
Specific NSF Requirement for Diabetes
162.1 162.1.1
Identifying persons to be screened The service shall support the identification of persons within a target group within a population who should receive screening for diabetes. This should be by calculation of a range of potential risk based on age, sex, and other pre-recorded risk factors and date of last screening (if any). A check should be made to see if an invitation has already been made in order to prevent duplication The service shall allow application of selection criteria to enable identification of patients to be invited for screening and those who should be screened opportunistically. Inviting persons to be screened and scheduling screening appointments The service shall allow the automatic production and dispatch of invitations to persons selected to be invited for diabetes screening. Invitations will generally require the person to contact a Primary Care clinic to arrange an appointment. The service shall allow the scheduling of appointments for screening for persons selected, by matching individuals to 103 Prevention, Screening and Surveillance 106 Clinical Documentation myhealthspace 103 Prevention, Screening and Surveillance
162.1.2
103 Prevention, Screening and Surveillance 105 Integrated Care Pathways and Care Planning
162.2
162.2.1
162.2.2
108 Scheduling
FINAL 1.0a
Page 498 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 109 eBooking 107 Care Management
162.2.3
162.2.4
162.2.5
162.3 162.3.1
available appointments within the required timescale. The service shall allow the monitoring and follow up of non-response to screening invitations within specified time periods from issue of the invitation. The service shall allow capture of the details of invitations issued, response and scheduled appointments within a comprehensive record for the person, which is capable of being accessed by other care professionals involved in the care of the person (in particular GPs). The service shall allow notification to responsible care professionals of outstanding non-responses to invitations. Undertake screening The service shall support the recording of details of attendance for screening, activities undertaken and care professional involved. The service shall provide decision support functionality with alerts and prompts to assist Clinicians in diagnosing diabetes including prompting for tests and investigations. The service shall support the recording of details of non-attendance and initiating follow up and further invitations (reflecting national and local standards and policies).
105 Integrated Care Pathways and Care Planning 107 Care Management
107 Care Management
107 Care Management
162.3.2
162.3.3
107 Care Management 108 Scheduling 109 eBooking 123 eHealth and Clinical Development and Clinical Deve lopment
162.4 162.4.1
162.4.2
Requesting investigations or analysis of specimens The service shall support requests for the analysis of specimens and dispatching these and capturing full details of the request in the persons record, ensuring that specimens are unambiguously associated with the person being assessed and the request. The service shall provide automatic receipt of results of tests requested and incorporation into a patients record.
110 Requesting and Order Communications
111 Results Reporting 123 eHealth and Clinical Development and Clinical Development
FINAL 1.0a
Page 499 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 109 eBooking
162.4.3
162.4.4
162.5 162.5.1
The service shall also support Primary Care professionals in referring patients for or requesting investigative procedures. Primary Care professionals should be able to search and retrieve information from service directories on-line, with point and click web style navigation to support booking of appointments. The service shall use protocols in making referrals, including prompts for the information required to support the referral and making this information available to the recipient of the referral. Assessment When a person has been diagnosed as having diabetes, the service shall support Clinicians and care professionals in assessing their ongoing care management needs. This requires context specific interfaces to provide access to existing relevant information, including information relating to other conditions, which may impact on the persons diabetes (prescriptions etc.). Also required is decision support for the capture of additional relevant information (e.g. based on agreed protocols using templates, prompts to record history, examination and baseline investigations. This may involve coded data, pick-lists and text) The service shall provide alerts and prompts for ordering of tests and investigations and where a referral may be appropriate given the results of examination or tests undertaken. The service shall have the ability to provide relevant information to the patient to support self-management, as hard copy or through other media. An alert may be sent (by text message or email for example) for the patient to contact his GP if a diagnosis of diabetes has been made and an early intervention is required. Specialist assessment and outcome
105 Integrated Care Pathways and Care Planning 107 Care Management 112 Decision Support 123 eHealth and Clinical Development and Clinical Development
162.5.2
112 Decision Support 123 eHealth and Clinical Development and Clinical Development
162.5.3
101 User Tools 106 Clinical Documentation 123 eHealth and Clinical Development and Clinical Development
162.6
FINAL 1.0a
Page 500 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 102 Patient Index 107 Care Management 123 eHealth and Clinical Development
162.6.1
162.7
162.7.1
162.7.2
162.7.3
When people with diabetes are referred for specialist secondary care assessment and treatment, it is essential that the details of the assessments and care are available to Primary Care Clinicians and others involved in the care of the patients. Therefore, the service shall support electronic notification to GPs of outcomes and proposed actions, including proposed treatment to stabilise condition and prescriptions. Develop care plan for initial stabilisation and ongoing maintenance of condition The service shall support Clinicians and care professionals in developing care plans for people with diabetes through context specific interfaces to access and capture information relevant to the development of the plan. The service, in this context, shall provide decision support based on protocols and / or guidelines to help develop care plan on the basis of information captured. The service shall provide the ability to allocate responsibilities for care inputs to appropriate care professionals and send them notifications. The service shall provi de the ability to produce copies of proposed care plans in order to discuss and agree components and responsibilities with patients. The service shall provide the ability to review and revise care plans on a regular basis,
105 Integrated Care Pathways and Care Planning 123 eHealth and Clinical Development
105 Integrated Care Pathways and Care Planning 107 Care Management myhealthspace 101 User Tools 107 Care Management 105 Integrated Care Pathways and Care Planning
162.7.4
162.7.5
162.8
162.8.1
Implement and monitor care plan, including monitoring by people with diabetes themselves The service shall support context specific access to patient information, and protocols to support encounters within a plan wherever care is being delivered, in order that implementation of the care plans for people with diabetes will involve a range of care inputs from different care professionals. This will also involve people with diabetes monitoring the status
FINAL 1.0a
Page 501 of 607
ICRS
of their own condition and sharing their observations with care professionals. 162.8.2 The service shall provide context specific recording of details of ongoing assessments/activities / actions undertaken (e.g. dates, durations etc.), the outcomes of care and progress in achieving care aims (including revised assessments). The service shall provide the ability to prescribe a whole range of medicinal products. The service shall support scheduling and booking of screening appointments, annual or more regular reviews, visits etc. The service shall provide context / condition specific support for patients to enable them to access their own records, to record their observations about both the status of their condition and the quality and outcomes of their care (including capture of results of self administered tests / measurements) and to share this information with care professionals. Referral to specialist service. (E.g. Secondary Care, podiatry, dietician, eye and foot screening A significant proportion of people with diabetes will be referred for specialist care. The service shall support the complete range of referral processes. The service shall provide decision support based on protocols or guidelines including: alerts and prompts where a referral is indicated as appropriate by guidelines; ordering of any pre-appointment tests, ordering and the automatic receipt results and incorporation into a patients record; warnings that receipt of referrals have not been acknowledged, and/or that appointments have not be scheduled in the timescales set out in protocol. 103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning 123 eHealth and Clinical Development 113 Prescribing and Pharmacy
162.8.3
162.8.4
108 Scheduling 109 eBooking myhealthspace
162.8.5
162.9
162.9.1
105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 110 Requesting Communications 112 Decision Support and Order
162.9.2
123 eHealth and Clinical Development
FINAL 1.0a
Page 502 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 109 eBooking 123 eHealth and Clinical Development
162.9.3
The service shall provide context specific interfaces providing access to information and support capture of information to support the referral for care professionals making referrals, including the booking of appointments. This should be supported by connections between various specialist services ( e.g. podiatry podiatry) and to primary care systems. The service shall provide access to details of local pathways specific for the relevant aspects of CHD or other occlusive arterial disease and associated referral guidelines or protocols. This will require knowledge of relevant and available clinics and appointments. The service shall support the abstraction from, or identification within, Patient Records of information required to support the referral, including: family history of diabetes; and the details and results of any tests already ordered or completed. Provision of regular screening and surveillance services (retinopathy screening A key component of the ongoing care of people with diabetes is retinopathy screening. The service shall support this and other screening activities which require support for: Rules based identification of individuals within target group to be screened / reviewed; Automatic issue of invitations to attend screening / review appointments; Scheduling of appointments and follow up of non responses to invitations; Capture of screening, review and treatment results; and Notification of results and follow up actions to patients and other care professionals.
162.9.4
106 Clinical Documentation 108 Scheduling 112 Decision Support 123 eHealth and Clinical Development 106 Clinical Documentation
162.9.5
162.10
162.10.1
103 Prevention, Screening and Surveillance 104 Assessment 106 Clinical Documentation 108 Scheduling 109 eBooking
FINAL 1.0a
Page 503 of 607
ICRS
162.11
Emergency care of diabetic patients (For either problems related to their diabetes or for unrelated problems) When people with diabetes require emergency care, it is important that the service shall provide full details of their condition and ongoing care are accessible. This requires support for: Context specific access to details of the patients current diabetic status, prescriptions and treatment plan; details of other conditions, prescriptions, and treatment ongoing; details of GP and the consultant providing care; The capture of details of emergency care provided; Notification to GPs, consultants and others providing ongoing care to the patient of the emergency care incident and outcomes.
106 Clinical Documentation 122 Emergency / Unscheduled Care 123 eHealth and Clinical Development
FINAL 1.0a
Page 504 of 607
ICRS
163 - CANCER Overview NSFs are not just about collecting data, and this part of the specification will not substitute for each LSP making particular reference to the specific documents available to help in satisfying cancer care policy and service requirements. Although the cancer NSF does not specify health promotion and lifestyle risk factors, these are generic to most of the other NSFs and should reasonably be addressed by modernisation strategies. It is recognised that every area of specialist activity will have variations in the data it uses and the way it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activity and monitoring, is specific to cancer services. The current development of cancer services is based upon the following initiatives: the White Paper The New NHS, Modern, Dependable (1997) which outlined the governments ten year strategy to modernise the NHS; the Calman/Hine Report A Framework for Commissioning Cancer Services (1995) which introduced the concept of Cancer Units and Cancer Centres and emphasised the importance of monitoring and audit of the quality of service provision; the NHS Cancer Plan (2000) which set out a 10 year programme to improve prevention, screening, early detection, treatment and care for people with cancer; Improving Outcomes cancer guidance, which sets out evidence-based guidance for individual cancers and tumour groups, to complement the Calman/Hine Report. Guidance covers breast, colorectal, lung, gynaecological, upper gastro-intestinal, urological, haematological and head and neck cancers; and the NHS Information Strategy Information for Health (1998) which set out a programme for meeting the information needs of the whole NHS.
Scope ICRS must support local communities and cancer networks in providing a full range of services for the prevention and treatment of cancer. The care of cancer patients comprises extensive care pathways, which in many instances involve inputs from different providers at different stages in the diagnosis and treatment of the disease. For some patients, these pathways will include independent, private and voluntary sector providers. cancer networks have been formally designated to work with patients, health professionals and managers to implement the NHS Cancer Plan. These networks cover substantial populations typically 1.5m or more - and may involve several care communities or Clusters of PCT and acute hospitals. Specialist diagnosis and/or treatment of cancer patients may be provided at one or more centres, supporting several health communities. Some networks extend across the boundaries of StHA. A key role of cancer networks is to ensure that the services that comprise these pathways are fully integrated, so that patients receive timely, effective and seamless care. ICRS solutions must support these network-based care pathways. For network-based services, which for some patients involve care pathways spanning several providers in different care communities or Clusters, ICRS solutions must support both local (Cluster specific) components of pathways, and the specialist components provided elsewhere (outside the Cluster). Videoconferencing, CPACS, and telepathology and ICRS have been shown to have specific applications in enabling effective cancer networks t function o
FINAL 1.0a
Page 505 of 607
ICRS
effectively. Special arrangements may be needed to ensure effective links to the many voluntary sector palliative care providers. The pathways for the care of different types of cancer may vary across cancer networks as may the detail. Governance and Audit Clinical Audit requires information to be assembled and analysed for every stage of the care pathway involved in the treatment of a patient with cancer. This pathway may involve care inputs from several organisations. Many audit questions initially require the aggregate analysis of non-identifiable data for populations of patients defined by commissioning or provider organisations; and by teams and individual Clinicians involved in the referral and treatment processes. Subsequently, depending o the results of this n analysis, there may be a requirement to assemble and analyse further information on a sub-set of the population of patients included within the initial analysis. Subsequently, there may be a need for clinical teams to view data relating to individual patients. This final drill down may require identifiable data. ICRS solutions must support audit of the delivery of appropriate and timely treatment, and monitoring of the processes involved in delivering cancer treatment including those associated with the elapsed times between stages within a patients pathway of care. In order to monitor these targets solutions must enable milestones within an individuals care pathway to be identified regardless of the location of service with which the patient interacts. The key functional groups within the National Dataset, which contain dates which support this monitoring, are: patient registration details; referral details; diagnosis details; care plan details; and treatment groups (surgical, chemotherapy, radiotherapy, etc.).
In order to monitor the consistency of performance across cancer networks, data need to be recorded consistently and be capable of being linked, aggregated and shared for benchmarking purposes. Data need to be structured to enable patient pathways to be comprehensively monitored and audited. Other requirements are to monitor survival rates, appropriateness of referrals and volumes of activity for specific cancer sites, by new referral and follow up cases. These are similar requirements to those identified as Clinical Audit questions. Service performance management activities require the aggregate analysis of non-identifiable data for populations of patients defined by organisations and clinical teams involved in the referral and treatment processes. Subsequently depending on the results of this analysis, there may be a requirement to assemble and analyse information on a sub-set of the population of patients included within the initial analysis. They generally do not require urther drill down to identifiable data on f individual patients. PCTs and the new Strategic Health Authorities will require data relating to cancer patient care spells, which may involve more than one organisation within a network (and sometimes beyond it). The service planning processes require the aggregate analysis of non-identifiable data for populations of patients. Subsequently depending on the results of this analysis, there may be a requirement to
FINAL 1.0a
Page 506 of 607
ICRS
assemble and analyse information on a sub-set of the population of patients included within the initial analysis. It does not require further drill down to identifiable data, on individual patients. The national cancer dataset comprises a consistent and transferable core dataset to meet the needs of Clinical Audit, assist in the generation of proposed National Performance Indicators, allow outcome assessment and provide the information required for Cancer Registries. A Cancer Registration minimum dataset has been defined consistent with the national cancer dataset, which cancer registries are expected to capture by April 2003. The dataset has been designed to reflect the treatment of patients across a managed network, with diagnostic and treatment events being provided by several different organisations within overall care spells for the treatment of a particular cancer. The dataset is also intended to be longitudinal, with groups of data items relating to reoccurrences of the disease and death. The dataset defines: standards for the definition and recording of specific data items, which should be reflected in the Patient Records and operational systems supporting the care of individual patients; and provides a structure for assembling or abstracting information from these records to support the analysis requirements of Clinical Audit, service planning and performance improvement / management and research.
The requirements for cancer services will be met through the application of the generic functions specified in modules 101-125. It is not the intention that any separate systems would be supplied to meet the needs of any condition-specific area. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of cancer service provision. In each case, reference has been made to relevant generic modules.
Specific NSF Requirement for Cancer
163.1 163.1.1
Identifying persons to be screened The service shall support: automatic selection of persons within a target group within a population who are eligible for screening within a particular time period. The population may be that registered with general practices within a care community; application of selection criteria, which reflect national standards for the screening programme. The characteristics of persons used for selection should be capable of being amended and extended. For NHS wide screening programmes, these must include personal characteristics such as age and sex, and the date of 103 Prevention, Screening and Surveillance
FINAL 1.0a
Page 507 of 607
ICRS
all previous screening episodes and their outcomes. 163.2 Inviting persons to be screened and booking a screening appointment The service shall support booking of appointments for screening at the screening centre for persons selected, by matching individuals to available screening appointments within the required timescale. This includes appointments at general practices for smears and PSA tests. The services shall support the ability to incorporate patient choice, including the ability for patients to make or change their appointments. Links to NHSD, NHSD online, kiosk and NHS Direct TV will be required. 163.2.2 The service shall provide automatic production and dispatch of invitations to persons selected for screening. For breast cancer screening, a specific appointment time will be provided. For cervical screening) the invitation may, in some instances, require the person to contact their general practice for an appointment. The service shall facilitate the dispatch of bowel cancer testing kits to persons homes, and the tracking of the return of these for analysis. The service shall monitor and allow follow up of non-responses to screening invitations within specified time periods from the issue of the invitation. The service shall capture the details of invitations issued, responses and booked appointments within a comprehensive record for the person, which is capable of being accessed by other care professionals involved in the care of the person (in particular GPs) and the 103 Prevention, Screening and Surveillance 108 Scheduling 109 eBooking
163.2.1
163.2.3
107 Care Management 110 Requesting and Order Communications
163.2.4
103 Prevention, Screening and Surveillance
163.2.5
FINAL 1.0a
Page 508 of 607
ICRS
screening process. 163.2.6 The service shall provide notification to responsible care professionals of outstanding non-responses to invitations. Undertaking initial screening investigations The service shall support care professionals in undertaking investigations to detect cancers. This may involve physical examination, imaging or the taking and analysis of specimens. Support is required for capturing details of attendance for screening, activities undertaken and care professionals involved. The service shall capture details of nonattendance and notifying relevant care professionals and initiating follow up and further invitations (reflecting national and local standards and policies). The service shall permit requesting analysis of specimens and dispatching these and capturing full details of the request in the persons record, ensuring that specimens are unambiguously associated with the person being screened and the request that was made. The service shall provide facilities for monitoring the progress of the request for analysis and highlighting when the results are overdue (reflecting agreed performance targets for the analysis of tests/specimens) and follow up actions are required. The service shall facilitate receipt of the results of analysis of specimens or of imaging undertaken and their inclusion within the persons comprehensive care record. This information must be accessible to authorised care professionals responsible for the ongoing care of the person, those involved in the screening process and those involved in subsequent assessment and treatment 109 eBooking 106 Clinical Documentation
163.3 163.3.1
104 Assessment 107 Care Management
163.3.2
105 Integrated Care Pathways and Care Planning 107 Care Management 109 eBooking
163.3.3
163.3.4
163.3.5
111 Results Reporting 115 Digital Imaging
FINAL 1.0a
Page 509 of 607
ICRS
either as a result of this screening or subsequently, when cancer is detected through other processes between screenings. 163.3.6 The service shall provide support for laboratories in relation to the receipt of specimens, the scheduling of analysis, the reporting of analysis and internal quality control. Quality assurance requirements are considered below, and other requirements are considered in section 3. Communicating and acting on results of screening The service shall provide support for care professionals following the results of initial screening tests and investigations. In particular, notifying the person screened of the results of the screening. The form of notification will reflect the results and the specific programme. Currently for breast cancer screening, a positive result will be accompanied by details of an appointment for further investigation. Currently for bowel cancer screening a positive result will be accompanied by an appointment with a care professional to review the results. For cervical screening and PSA testing, this will involve an appointment with a GP which may lead to referrals for specialist assessment and diagnosis. 163.5 163.5.1 Assessment and further investigation The service shall support the assessment and further investigation of persons within the breast and bowel screening programmes whose initial test or investigation results are positive. Currently this applies to breast and bowel but in the future screening for other 103 Prevention, Screening and Surveillance 104 Assessment Assessment 125 Surgical Interventions 106 Clinical Documentation 110 Requesting and Order Communications 111 Results Reporting 114 Diagnostic and Investigative Services Departments
163.4
163.4.1
FINAL 1.0a
Page 510 of 607
ICRS
cancers may be introduced. In the case of bowel cancer screening, this may involve an investigative procedure (colonoscopy). These processes are undertaken as an integral component of the overall screening process. In breast screening it will involve all processes required to make a diagnosis, including open surgical biopsy under general anaesthetic. These processes are similar to those required in the care of patients for whom a suspected cancer is detected outside a screening programme. 163.6 163.6.1 Referrals by primary care clinicians. The components of the service used by care professionals within primary care, and in particular general practitioners, shall support the referral of patients with suspected cancer for specialist assessment and diagnosis, and the monitoring of the progress of these referrals. Referral processes must be supported by context specific interfaces. If indicated by agreed local protocols these referrals may take the form of a store and forward referral. 163.6.2 The service shall allow users to access details of local pathways specific to the suspected tumour site and associated referral guidelines or protocols. The service shall allow users to access information regarding waiting times, specialist services and clinical outcomes at local and distant provider sites. The service shall permit automatic assembly and retrieval of relevant information from the patients record including: details of patients lifestyle; (current and previous consumption of 112 Decision Support 106 Clinical Documentation 123 eHealth and Clinical Development
163.6.3
350 Spine Directory Services
163.6.4
FINAL 1.0a
Page 511 of 607
ICRS
tobacco and alcohol etc.); family history of cancer; symptoms and duration; and the details and results of any diagnostic tests already ordered or completed. 112 Decision Support
163.6.5 The service shall allow decisions based on protocols or guidelines, including: alerts and prompts where a referral is indicated as appropriate given the results of examination or tests undertaken and for ordering of preappointment tests; protocols to ensure referrals are made to appropriate specialist services; and warnings that receipt of referrals have not been acknowledged, and/or that appointments for assessment have not been scheduled in the timescales set out in protocols. The service shall permit capture of information to support the referral including: automatic receipt of results of tests requested and incorporation into a patients record; and details of the referral, e.g. urgency, date and time of referral, recipient and destination etc. 109 eBooking 106 Clinical Documentation
163.6.6
163.6.7
The service shall facilitate transfer of referral Information and booking of assessment appointments including: electronic transfer of referral information (or notification of referral and authority to access relevant information); and provision of details of the referral and any booked assessment appointment to the patient.
FINAL 1.0a
Page 512 of 607
ICRS
163.7 163.7.1
Referrals from other sources The service shall support referrals for assessment and diagnosis which are received from a range of sources other than primary care. These include: presentation with symptoms, which may suggest cancer at accident and emergency or an open access clinic; and as a result of a suspected cancer being detected during assessment or treatment of another condition or disease including through imaging requested as part of this assessment. 106 Clinical Documentation
Similar support is required for care professionals making these referrals to that for primary care clinicians outlined above. It is important that details of the referral, results of tests undertaken etc. are captured within Patient Records and that relevant care professionals are notified of the referral, in particular the GP with whom the patient is registered. 163.8 163.8.1 Managing the receipt of referrals When referrals of patients with a suspected cancer for assessment are received, the service shall provide support for the management of the referrals. This must be supported by context specific interfaces providing care professionals with the following functionality: access to details of local pathways specific to the suspected tumour site and associated referral guidelines or protocols; access to the information provided with the referral, covering signs and symptoms, the details and results of any diagnostic tests already ordered or completed etc.; and the capacity to respond to a store and forward referral with opinion, advice or a request for physical referral (with or without further tests or investigations 104 Assessment 105 Integrated Care Pathways and Care Planning 107 Care Management 123 eHealth and Clinical Development
FINAL 1.0a
Page 513 of 607
ICRS
in the interim). 163.8.2 The service shall enable the capture of information to support the monitoring of the progress of care including: details of the receipt of the referral, for example date and time of receipt source etc; details of proposed actions; transfer of Information; and notification of receipt of referral to referrer and patient and proposed actions. 104 Assessment 105 Integrated Care Pathways and Care Planning 109 eBooking
163.9 163.9.1
Booking assessment appointments The Service shall support the booking of assessment appointments for cancer patients. This functionality is similar to that required for patients with other suspected conditions and covers, for example, support for: identifying available appointments, taking into account urgency of referral, clinical staff availability, facilities and equipment, tests and investigations to be undertaken prior to appointment etc.; alerting care professionals and others if there are no apparent available appointments within target elapse times for assessment from date of referral as set out in guidelines and protocols; scheduling the appointments so that the patient does not have to duplicate unnecessarily visits to the same site; notification to the patient (and carer in some circumstances) of appointment time and date; receipt of confirmation of attendance or otherwise and rescheduling if necessary; and ordering patient transport where necessary. 108 Scheduling 109 eBooking
163.10
Ordering investigations and tests and receiving results
FINAL 1.0a
Page 514 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 104 Assessment 110 Requesting and Order Communications 111 Results Reporting
163.10.1
The service shall support clinicians in determining whether patients referred with suspected cancers have the disease. This will require tests, investigations and examinations to be undertaken and the subsequent review of the results of these. Some tests and investigations may need to be completed prior to an assessment appointment. The generic functionality required is again similar to that required to support diagnosis of other diseases, although the types of tests and investigations undertaken and the detailed information required to support these may be specific to the suspected cancer. This covers support for: the capturing of additional information for example lifestyle details, family history and symptoms not included in the referral; taking specimens and requesting their pathological analysis; requesting the analysis of specimens and dispatching these and capturing full details of the request in the persons record, ensuring that specimens are unambiguously associated with the person being screened and the request; requesting investigative procedures and imaging; and providing details of patient, investigation or imaging required, urgency etc. and capturing full details of the request in the persons record.
Solutions should support clinicians requesting these services in monitoring the progress of the request for analysis, identifying when the results are overdue and follow up actions are required. 163.11 Support for investigations analysis of specimens and
The service solutions must support care professionals in responding to requests for investigations, imaging and pathological analysis of specimens. The
110 Requesting and Order Communications 111 Results Reporting 115 Digital Imaging
FINAL 1.0a
Page 515 of 607
ICRS
functionality required is similar to that required for requests associated with the diagnosis of patients with other conditions or diseases. 163.12 163.12.1 Investigative procedures These may involve for example endoscopy, colonoscopy, colposcopy etc. The service shall provide support for: the receipt of requests and samples; acknowledgement of the receipt of the request; access to details of request, and capture of the date request received; and booking the attendance of the patient for the procedure in line with protocols/guidelines, notifying the patient and confirming attendance and notifying the requestor of planned date and time of report. The service shall support undertaking the investigation and in particular, the automatic capture of images from video scopes with the ability to annotate and store these in a searchable f rm within o Patient Records. This will increasingly be done in primary care or DTCs and so the system shall support remote clinics including the transfer of an image along with the relevant history to an expert for a second opinion or quality improvement (store and forward). This shall include video clip images such as from a colposcope. 163.12.3 The service shall support reporting and in particular: preparation of report in structured form and capture of reporting details (date, responsible clinician etc.); maintenance of reports in Patient Record accessible to all authorised care professionals involved in providing care to the patient; 111 Results Reporting 109 eBooking 110 Requesting and Order Communications 111 Results Reporting
163.12.2
115 Digital Imaging
FINAL 1.0a
Page 516 of 607
ICRS
support for use of standard terms, codes and classifications; and notification to requestor (or dispatch) of completed report.
163.13 163.13.1
Imaging The service shall support receipt of requests for imaging and is similar to that for investigative procedures outlined above. Requests for imaging will include details of the modality i.e. technique and/or equipment to be used to produce the image and the anatomical site to be examined. The service shall support the capture, management and presentation of the whole range of imaging modalities including but not limited to: standard radiography; chest X-ray; sinus X -rays; mastoid views; orthopantomogram (OPG); skull base views; CT Scan with and without contrast; MRI scan with and without contrast; PET scan; ultrasound; nuclear Medicine imaging; bone scan; other isotope scan; ventilation/perfusion scan; mammography; barium, barium swallow; and lymphoscintigraphy. enema, barium 114 Diagnostic and Investigative Services Departments 115 Digital Imaging
163.14
Pathology
FINAL 1.0a
Page 517 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 110 Requesting and Order Communications 111 Results Reporting 114 Diagnostic and Investigative Services Departments 115 Digital Imaging
163.14.1
The service shall provide support for the receipt of requests and samples including:
acknowledgement of the receipt of the request; access to details of request and capture of the date both specimen and request received; ensuring exact matching of requests to specimens received; scheduling the analysis of specimens and subsequent reporting, in line with protocols and the notification of the requestor of planned date/time of report (scheduling should take account of availability of equipment and staff); and monitoring progress of the analysis and identifying due and overdue actions.
The service shall provide support for the analysis of specimens including: capture results of tests automatically from medical equipment; and capture of the details of the analysis (in line with minimum standards as set out in Core Cancer Dataset); and,
The service shall provide support for reporting including: preparation of report in structured form and capture of reporting details (date, responsible clinician etc.); maintenance of reports in Patient Record accessible to all authorised care professionals involved in providing care to the patient; support for use of standard terms,
FINAL 1.0a
Page 518 of 607
ICRS
codes and classifications; and 163.15 163.15.1 notification to requestor (or dispatch) of completed report. Diagnosis The service shall enable clinicians to easily capture the details of the diagnosis within patients records. These details should be captured within a comprehensive record for the patient, which is capable of being accessed by all authorised care professionals involved in the subsequent care of the person, including general practitioners. The diagnosis details captured should as a minimum be consistent with the content and standards set out in the Core Cancer Dataset. Notifying the patient of the outcomes of the assessment and diagnosis will involve an appointment with the clinician and solutions must support the booking of these subsequent appointments. This shall include automatic notification of the cancer registry. 163.16 Support for Multidisciplinary (MDT) meetings Team 104 Assessment 107 Care Management 108 Scheduling 109 eBooking
163.16.1
The service shall support preparation for MDT meetings by creating an agenda of patients scheduled to be discussed at the MDT meeting. MDT meetings may involve care professionals from a number of different organisations based in different locations across a Network. These meetings may take the form of video conferences. The service shall provide support for the scheduling of MDT meetings including: selecting dates and times taking into account standards for the time between diagnosis and formal reviews as set out in national and local guidance and the availability of
108 Scheduling
163.16.2
108 Scheduling 109 eBooking 123 eHealth and Clinical Development
FINAL 1.0a
Page 519 of 607
ICRS
care professionals and facilities; notifying care professionals involved, monitoring responses and confirmation of attendance; and booking facilities and equipment
This should be able to b provided in the e form of a configurable report including images for each patient so as to provide the basis for the discussion of each patient at the MDT meeting. This report and the images may be displayed at the MDT meeting and shared in a video conference. 163.16.3 The service shall provide access to information which all care professionals involved in MDT must be able to access and discuss such as comprehensive records relating to the patient concerned, including details of personal characteristics, lifestyle characteristics, family history, referrals, results of pathological analysis and other investigations, such as relevant images, diagnosis and treatments already provided as a component of this care spell and outcomes, previous occurrences and care plans, complications etc. The service shall facilitate capture of information into patients records including: details of the date of, and attendance at the MDT meeting; and details of outcomes of MDT meetings and in particular treatment decisions, the agreed care plan and the patients performance status. The information captured should be consistent with the content and standards set out in the Core cancer Dataset. 106 Clinical Documentation 109 eBooking 104 Assessment 107 Care Management
163.16.4
163.16.5
The service shall support notifying the patient and other care professionals including: notifying the patient of the outcomes
FINAL 1.0a
Page 520 of 607
ICRS
of the M DT meeting may involve an appointment with the clinician and solutions must support the scheduling of these subsequent appointments; solutions should enable general practitioners to be notified of the outcomes of the MDT meeting and to access details of the cancer care plan; solutions should also support the production of advice to patients (and carers) on the nature and implications of proposed treatment modalities; and patient access to their records shall also be supported to specifically meet this requirement.
163.17 163.17.1
Staging The service shall support clinicians in classifying the tumour and capturing details of staging using the agreed coding system (currently UICC). This information should be captured within Patient Records at the time of agreement of the first cancer care plan. The information captured should be consistent with the content and standards set out in the Core Cancer Dataset The staging systems currently used for those cancers for which there are screening programmes are: breast: NPI (Nottingham Prognostic Index); colorectal: Dukes; and cervix: FIGO 104 Assessment
Other staging systems in use for possible screening programmes include: prostate: Gleason score (This shall be scaleable to include new or changing staging systems and to enable a change in staging at MDT meetings or operation along with a reason why, the Cancer Registry should also be
FINAL 1.0a
Page 521 of 607
ICRS
notified). 163.18 163.18.1 Surgery The support that shall be provided within the service for surgical treatment of patients with cancer is similar to that for all patients requiring surgical interventions as inpatient or day-cases. Solutions shall provide clinicians and others involved in the care with access to comprehensive Patient Records including details of current diagnosis, care plan, tests and imaging undertaken and history of previous surgical treatment including any complications and reactions to anaesthetics etc. 163.18.2 The service shall support for the planning of surgery including: the capture of details of decisions to treat, the date and the target date for treatment to commence given national standards for patient and tumour site/cancer and the treatment given; scheduling of pre-admission tests; scheduling of admission; scheduling of post-admission tests; requesting and booking theatre time and resources; planning post operative and discharge care and support; notifying the patient of admission and procedure; planned 104 Assessment 105 Integrated Care Pathways and Care Planning 107 Care Management
101 User Tools 108 Scheduling 109 eBooking 110 Requesting and Order Communications 111 Results Reporting
receiving patient confirmation (or otherwise) of consent and attendance for surgery; notifying other care professionals involved in care plan; and comparing planned date of surgery with targets and capture reasons for
FINAL 1.0a
Page 522 of 607
ICRS
variation. 163.18.3 The service shall provide support for the admission of patients and the provision of surgery including the capture of full details of the admission, procedures undertaken, clinical support provided (anaesthetics etc.), complications and theatre resources used; compare actual and planned dates of surgery and capture reasons for variation; and support for the planning and provision of post surgical care and support, including after discharge. 105 Integrated Care Pathways and Care Planning 107 Care Management 125 Surgical Interventions
163.19
Chemotherapy - Much of this support is specific to the treatment of cancer The service shall provide support for the provision of chemotherapy treatment of patients with cancers. The functionality required covers access to comprehensive Patient Records including details of current diagnosis, care plan, tests and imaging undertaken and history of previous treatments, including any complications and reactions to drugs administered etc. The service shall support the planning of treatment, ncluding access to protocols i and guidelines to assist in determining the appropriate therapy type and regimen etc. The service shall enable clinicians to: capture details of decision to treat, date, consultant etc. and target date for treatment to commence given national standards for patient and tumour site/cancer and the treatment content; capture details and patient characteristics used in decisions including renal function; 104 Assessment 105 Integrated Care Pathways and Care Planning
163.19.1
163.19.2
104 Assessment 106 Clinical Documentation 107 Care Management
FINAL 1.0a
Page 523 of 607
ICRS
notify patient and provide information on treatment and possible responses; and
163.19.3
notify other care professionals involved in care plan. The service shall support the prescription of drugs planned dosage, cycle, frequency of administration as well as: capture of the details of prescription; scheduling events; notification pharmacist events; of to of drug administration
113 Prescribing
the dispensing prescription and
notification to the patient of schedule of events; receipt of patient confirmation (or otherwise) of consent and attendance for scheduled treatment; notification to other care professionals involved in care plan; comparison of treatment start date with targets and the capture of reasons for variation; dispensing of the drugs prescribed; and capture details of events and doses, care professionals involved and highlight variations from prescription.
The service shall also support the abstraction of data to support stock control, reordering of stocks etc. 163.19.4 The service shall support administration of the drugs prescribed through the capture of details of events and doses. Care professionals involved are identified and variations from prescription are highlighted. The services shall support fail safe 113 Prescribing
FINAL 1.0a
Page 524 of 607
ICRS
patient safety processes to ensure right patient, right dose, right time, right route including a link to verification solutions, patient / clinical ID and CPOE systems. The service shall also include warnings at times on known risk e.g. intrathecal vincristine. 163.19.5 The service shall allow review of the response to treatment so as to enable: capture of the details of the response; and 113 Prescribing 106 Clinical Documentation
163.20 163.20.1
notification of response to other care professionals involved in the care plan. Radiotherapy (Teletherapy) The service shall provide access to Patient Records and details of diagnosis, staging and care plans etc. 104 Assessment 105 Integrated Care Pathways and Care Planning 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation
163.20.2
The service shall allow capture of details of the decision to treat, date, consultant involved etc. and target date for treatment to commence given national standards for patient and tumour site/cancer and the treatment content. Notification to the patient and provision of information on treatment and possible responses.
163.20.3
The service shall provide support for the prescribing of teletherapy treatment intent and site, dose, number of fractions, duration, beam type and energy, anaesthetic requirements, including capture of prescription; the details of the
113 Prescribing
scheduling of treatment events; notification to care professionals involved of prescription and events; notification to the patient of the
FINAL 1.0a
Page 525 of 607
ICRS
schedule of events; receipt patient confirmation (or otherwise) of consent and attendance for scheduled treatment; comparison of treatment start date with targets and the capture of reasons for variation, ensuring fail safe patient safety mechanisms are incorporated. 101 User Tools
163.20.4
The service shall support the provision of teletherapy. It shall: capture details of events and fractions given, care professionals involved and highlight variations from prescription; allow reviewing treatment; and the response to
163.21 163.21.1
permit classification of the treatment according to complexity.
Radiotherapy (Brachytherapy) The service shall provide support for the provision of brachytherapy treatment of patients with cancers. This support is specific to the treatment of cancer. The functionality required is similar to that set out above for teletherapy and covers: access to Patient Records and details of diagnosis, staging, care plan etc.; support for the planning of treatment (as above); support for the prescribing of brachytherapy treatment intent and site, type of brachytherapy, dose, number of fractions, duration, radiation source, delivery type, anaesthetic requirements (as above); support for the provision brachytherapy (as above); and of
As above for Teletherapy
reviewing the response to treatment (as above).
FINAL 1.0a
Page 526 of 607
ICRS
163.22 163.22.1
Palliative Care The service shall support the provision of palliative care as a component of a patients cancer plan. Palliative care may be provided in a range of care settings, which may be NHS, private, or voluntary, and will include: acute hospitals; hospices; day therapy centres; and patients homes. 123 eHealth and Clinical Development
Care will be provided by multidisciplinary teams comprising consultants, specialist nurses, therapists and social care professionals and the patients own carers. These teams may comprise staff employed by a range of agencies including independent sector organisations, and may not necessarily make up a specialist palliative care team. Provision of this service may involve the use of remote monitoring and virtual visiting. 163.22.2 The service shall support prescribing, dispensing and administration of medication to relieve adverse symptoms. The service shall support counselling, support and advice to patients including: scheduling of visits; production of advisory materials; and capture of details of patients signs and symptoms and response to medication or treatment, including self-recording or recording by carers. 108 Scheduling 109 eBooking 113 Prescribing
163.22.3
108 Scheduling 109 eBooking 112 Decision Support
163.22.4
The service shall support requesting and scheduling admission to hospice beds, including notification of that request or admission to health professionals involved in the care of that individual.
FINAL 1.0a
Page 527 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 112 Decision Support
163.22.5
The service shall support access to decision support mechanisms including clinical guidelines and education in their use.
FINAL 1.0a
Page 528 of 607
ICRS
164 - CORONARY HEART DISEASE Overview NSFs are not just about collecting data, and this part of the specification will not substitute for each LSP making particular reference to the specific documents available to help in satisfying Coronary Heart Disease (CHD) care policy and service requirements. It is recognised that every area of specialist activity will have variations in the data it uses and the way it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activity and monitoring, is specific to CHD. The CHD NSF, published in March 2000 and which can be found at the URL, <http://www.doh.gov.uk/nsf/coronory.htm>, provides the policy core for the information strategy and was reinforced by the NHS Plan. The NSF sets the agenda for the modernisation of CHD services over the next ten years. It sets twelve standards for improved prevention, diagnosis and treatment, and goals to secure fair access to high quality services over a ten-year period. The coronary heart disease information strategy aims to provide standards for health care services which will improve the quality of care and reduce unacceptable variations. The NHS Plan described a patient focussed approach to cardiac care-based on CHD networks. These networks bring together all of the providers and commissioners of cardiac care in an area to plan, deliver and monitor the quality of services. The aim is to co-ordinate the delivery of integrated care across the care pathway, regardless of the clinical setting in which the care is delivered. ICRS must support these pathways. Scope ICRS must support local communities in providing a full range of services for the prevention and treatment of CHD or other occlusive arterial disease. These will comprise: prevention services, which target those at risk of developing CHD or other occlusive arterial disease within local populations, providing opportunities for regular screening and assessment of risk and support and care to enable at risk people to modify these risks; screening, assessment and review of patients, who have CHD, or other occlusive arterial disease, with or without angina; the specialist assessment and diagnosis of patients with suspected CHD, or other occlusive arterial disease, and where appropriate their planned treatment; the emergency care of patients with CHD or other occlusive arterial disease; and the rehabilitation of patients following treatment for CHD or other occlusive arterial disease. The specific support required for a number of these service components is: prevention and screening; lifestyle modification; planned Secondary Care; and emergency care.
Governance and Audit ICRS must support the selection and abstraction of data from Patient Records in order to support both operational management of services and audit, performance management and review of services. Clinical Audit requires information to be assembled and analysed for every stage of the care pathway involved in the treatment of a patient with CHD or other occlusive arterial disease. This pathway may involve care inputs from several trusts.
FINAL 1.0a
Page 529 of 607
ICRS
ICRS must also enable data to be abstracted and assembled to support clinical management dataset for rapid access chest pain clinics and the core dataset for acute myocardial infarction. See these at the URLs, <http://www.nelh.nhs.uk/heart/racpcs/dataset/RACPC_Intro.htm> and <http://www.rcplondon.ac.uk/college/ceeu/ceeu_ami_home.htm>, respectively. These audit requirements will initially require the aggregate analysis of non-identifiable data for populations of patients defined by organisations; teams and individual Clinicians involved in the referral and treatment processes. Subsequently depending on the results of this analysis, there may be a requirement to assemble and analyse further information on a sub-set of the population of patients included within the initial analysis. Subsequently, there may be a need to view data relating to individual patients. This final drill down may require identifiable data. ICRS must support the abstraction of data to enable monitoring of quality targets for the processes involved in delivering care for CHD or other occlusive arterial disease, particularly those associated with "call to needle time" and "door to needle time" for thrombolysis for eligible patients, and the elapsed times between referral and first appointment and decision to admit for surgery and the date of the procedure. The key functional groups within the National Common Minimum Dataset, which contain dates which support this monitoring, are: patient registration details; attendance details; referral details; diagnosis details; waiting list details; and procedure details.
Other requirements are to monitor appropriateness of referrals and volumes of activity for CHD or other occlusive arterial disease, by new referral and follow up cases. These are similar requirements to those identified as Clinical Audit questions. Service performance management activities require the aggregate analysis of non-identifiable data for populations of patients defined by organisations and clinical teams involved in the referral and treatment processes. Subsequently depending on the results of this analysis, there may be a requirement to assemble and analyse information on a sub-set of the population of patients included within the initial analysis. They generally do not require further drill down to identifiable data on individual patients. For service performance monitoring purposes, data are required at regular intervals. Data must be up to date and are usually required to be no more than three months old. PCTs and the new StHAs will require data relating to CHD or other occlusive arterial disease patient care spells, which may involve more than one organisation. Work has and is being undertaken to define a number of CHD core datasets relating to different components of the care of patients at risk of or with CHD or other occlusive arterial disease. These datasets define: standards for the definition and recording of specific data items, which should be reflected in the integrated care records supporting the care of individual patients; and a structure for assembling or abstracting information from these records to support the analysis requirements of Clinical Audit, service planning and performance monitoring.
ICRS must support these datasets.
FINAL 1.0a
Page 530 of 607
ICRS
NICE are due to publish clinical guidelines for the management of patients with heart failure in mid 2003. The ICRS will need to support delivery of this complex agenda covering primary, secondary and tertiary services and interfacing with social care services.
The requirements for CHD will be met through the application of the generic functions specified in modules 101-125. It is not the intention that any separate systems would be supplied to meet the needs of any condition-specific area. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below and must identify any specific additional features required to support the needs of CHD. In each case, reference has been made to relevant generic modules.
Specific NSF Requirement for Coronary Heart Disease
164.1 164.1.1
Identifying persons to be assessed The service shall support the systematic recording of major risk factors for relevant patients registered with general practitioners. This will include prompting for factors such as smoking, BMI and family history of CHD or other occlusive arterial disease. For new patients this information should be prompted for at the new patient visit. For existing patients there should be prompting where there is incomplete basic risk information. The service shall support: identification of persons within a target group within a p opulation who should receive full assessment of CHD risk. This should be by calculation of a range of potential risk based on pre-recorded risk factors and co-morbidities. This should include cross links between disease registers e.g. between diabetes and CHD; and application of selection criteria to enable identification of patients to be invited for assessment and those who should be assessed opportunistically. myhealthspace 101 User Tools 103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning
164.1.2
103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning
164.2
Inviting persons to be assessed and scheduling assessments The service shall support the automatic production and dispatch of invitations to persons selected to be invited for 103 Prevention, Screening and Surveillance
164.2.1
FINAL 1.0a
Page 531 of 607
ICRS
assessment. Invitations will generally require the person to contact a primary care clinic to arrange an appointment. 164.2.2 The service shall allow the scheduling of appointments for assessment for persons selected by matching individuals to available assessment appointments within the required timescale. This also includes capture of the details of invitations issued, response and scheduled appointments within a comprehensive record for the person, which is capable of being accessed by other care professionals involved in the care of the person (in particular GPs). 164.2.3 The service and follow assessment time periods shall provide the monitoring up of non-responses to invitations within specified from issue of the invitation. care non105 Integrated Care Pathways and Care Planning 107 Care Management 103 Screening, surveillance and prevention 106 Clinical Documentation 108 Scheduling 109 eBooking
164.2.4
Notification to responsible professionals of outstanding responses to invitations.
The service shall provide facilities to support the achievement of compliance. The services shall support the ability to include informed refusal by a patient to be screened. 164.3 164.3.1 Undertaking screening or assessment The service shall support the capture of information and provide care professionals with context specific prompts to record modifiable risk factors for patients, and retrieve relevant preexisting data in particular for those patients already identified as at risk of CHD. This will include factors such as smoking, BMI, diet, exercise, alcohol consumption, blood pressure and lipids (e.g. factors required for calculation of risk). The service shall record details of attendance for assessment, activities undertaken and care professionals involved. The service shall also record details of non-attendance and initiating 101 User Tools 104 Assessment 107 Care Management 112 Decision Support 123 eHealth and Clinical Development
164.3.2
FINAL 1.0a
Page 532 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 107 Care Management 109 eBooking
follow up and further invitations (reflecting national and local standards and policies).
164.4
Requesting investigations or analysis of specimens The service shall support assessment which may involve the taking of specimens e.g. to confirm levels of cholesterol. The service shall support: requests for the analysis of specimens and dispatching these and capturing full details of the request in the person's record, ensuring that specimens are unambiguously associated with the person being assessed and the request; and automatic receipt of results of tests requested and incorporation into a patients record. The service shall also support primary care professionals in referring patients for or requesting investigative procedures. They should be able to: search and retrieve information from service directories on-line with point and click web style navigation: book appointments for patients; and use protocols in making referrals, including prompts for the information required to support the referral and making this information available to the recipient of the referral. 110 Requesting and Order Communications 111 Results Reporting 108 Scheduling 109 eBooking 112 Decision Support myhealthspace 104 Assessment 106 Clinical Documentation 110 Requesting and Order Communications 111 Results Reporting
164.4.1
164.4.2
164.5 164.5.1
Calculation of risk The service shall support calculation of risk dependent, taking all recorded risk factors into account and the recalculation of risk on a regular basis to take account of changes as a result of ageing or whenever more information is available (such as test results). 104 Assessment
FINAL 1.0a
Page 533 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide myhealthspace 104 Assessment 105 Integrated Care Pathways and Care Planning
164.5.2
The service shall allow notifying the person assessed of the results of the assessment. This will normally be during the assessment consultation, but results of further tests may modify the risk calculation and patients should be informed of substantial changes in their calculated risk. Advice and treatment to reduce risk The service shall support: the provision of advice to patients quantifying the additional risk arising out of the lifestyle and characteristics of the patient and outlining strategies for modifying lifestyle to reduce risk (e.g. providing copies of risk factor results to support them in losing weight, reducing cholesterol levels, BP etc); and identifying lifestyle modification programmes available (this type of information shall be made available in variety of formats, languages and levels of detail appropriate to the purpose and the person receiving the information).
164.6 164.6.1
myhealthspace 101 User Tools 103 Prevention, Screening and Surveillance 105 Integrated Care Pathways and Care Planning 112 Decision Support
164.6.2
The service shall provide facilities which allow prompting for and enabling the prescription of pharmacotherapies, such as low dose aspirin to reduce risk. Prompts and warnings should be based on agreed guidelines and reflect relevant patient characteristics and previous medical history and allergies etc. The service shall support practice based audit tools to support quality improvement programmes in relation to pharmacotherapies and other preventive efforts.
112 Decision Support 113 Prescribing and Pharmacy
164.7
Referrals to programmes
lifestyle
modification
164.7.1
The components of the service used by care professionals within both primary
myhealthspace
FINAL 1.0a
Page 534 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 108 Scheduling 109 eBooking 123 eHealth and Clinical Development
and secondary care shall support the referral of patients to appropriate lifestyle modification programmes such as smoking cessation clinics, the monitoring of the progress of these referrals, and the longer term follow up on the success of any programme. The service shall provide context specific interfaces for care professionals making referrals, including the booking of appointments. 164.7.2 The service shall provide access to details of: local pathways specific for the relevant aspects of CHD or other occlusive arterial disease and associated referral guidelines or protocols; and relevant and available clinics and appointments.
myhealthspace 108 Scheduling 109 eBooking 112 Decision Support 123 eHealth and Clinical Development
164.7.3
The service shall support the abstraction from or identification within Patient Records of information required to support the referral including: details of patients lifestyle (current and previous consumption of tobacco and alcohol etc.); family history of CHD or occlusive arterial disease; and other
106 Clinical Documentation 109 eBooking
164.7.4
the details and results of any tests already ordered or completed. 112 Decision Support
The service shall provide decision support based on protocols or guidelines including: alerts and prompts where a referral is indicated as appropriate; ordering of any pre-appointment tests; and warnings that receipt of referrals have not been acknowledged and/or that appointments have not be scheduled
FINAL 1.0a
Page 535 of 607
ICRS
in the timescales set out in protocols. 164.8 164.8.1 Managing the receipt of referrals The service shall provide support for care professionals in smoking cessation clinics or other lifestyle modification programmes. The service shall provide context specific interfaces for care professionals to enable them to manage referrals. myhealthspace 103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 107 Care Management 123 eHealth and Clinical Development 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation
164.8.2
The service shall provide access to information on lifestyle factors recorded within the patients records required to inform the care requested (e.g. smoking history, previous attempts to quit, and contribution to overall risk). The service shall enable care professionals to capture and record information to support the monitoring of the progress of care including: details of the receipt of the referral, for example - date and time of receipt source etc; and details of proposed actions.
164.8.3
164.8.4
The service shall enable notification of receipt of a referral to both the referrer and patient together with proposed actions. Scheduling of appointments group or individual
164.9
164.9.1
The service shall support: the scheduling of clinic appointments; the monitoring and follow up of nonresponse or attendance; capture of the details of invitations issued, response and scheduled appointments and attendance; and notification to responsible care professionals of non-responses or
106 Clinical Documentation 107 Care Management 108 Scheduling 109 eBooking
FINAL 1.0a
Page 536 of 607
ICRS
non-attendances. 164.10 164.10.1 Outcomes of programmes The service shall ensure that when people with, or at risk from, CHD or other occlusive arterial disease are referred to lifestyle modification programmes it is important that the outcomes of the care provided are available both to primary care clinicians and others involved in the care of the patients, and to those responsible for the programmes. The service shall enable details of modifications to lifestyles to be captured and recorded both: through regular screening assessment (see above); and and myhealthspace 103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning 123 eHealth and Clinical Development
through providing the patient with access to their own records for selfrecording of observations and measurements. 103 Prevention, Screening and Surveillance 104 Assessment 105 Integrated Care Pathways and Care Planning
164.10.2
Within the service, care professionals providing lifestyle modification programmes shall, with appropriate authentication, be able to access longitudinal Patient Records to monitor the longer-term success of interventions, e.g. if the patient is still not smoking a year after attending a smoking cessation programme. Booking and scheduling assessment appointments The service shall support the scheduling of assessment appointments for CHD patients. This functionality is similar to that required for patients with other suspected conditions and covers support for: identifying and booking appointments, taking into account urgency of referral, clinical staff availability,
164.11
164.11.1
FINAL 1.0a
Page 537 of 607
ICRS
facilities and equipment, tests and investigations to be undertaken prior to appointment etc. (appointments for tests and investigations should be booked simultaneously to minimise patient journeys); alerting care professionals and others if there are no apparent available appointments within target elapse times for assessment from date of referral as set out in guidelines and protocols; notification to the patient (and carer in some circumstances) of appointment time and date; and receipt of confirmation of attendance or otherwise and rescheduling if necessary. The service shall provide comprehensive practice based disease registers available and collatable across clinical networks.
164.12 164.12.1
Assessment The service shall provide context specific interfaces to provide access to information recorded in patients records including that relating to other conditions such as diabetes which may impact on a person's CHD. The service shall provide support for the capture of additional information based on agreed protocols or guidelines providing prompts to record history, examination and baseline investigations. The service shall support the capture and recording of the results of examinations, tests and investigations consistent with the minimum dataset defined for rapid access chest pain clinics. 104 Assessment
164.12.2
104 Assessment 105 Integrated Care Pathways and Care Planning 110 Requesting and Order Communications 111 Results Reporting 112 Decision Support 123 eHealth and Clinical Development
164.12.3
The service shall provide alerts and prompts for ordering of tests and investigations and where a referral may
FINAL 1.0a
Page 538 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide of 110 Requesting and Order Communications 112 Decision Support
be appropriate given the results examination or tests undertaken.
164.12.4
The assessment may involve the taking of specimens and the service shall support: requests for the analysis of specimens and dispatching these and capturing full details of the request in the persons record, ensuring that specimens are unambiguously associated with the person being assessed and the request; and automatic receipt of results of tests requested and incorporation into a patients record.
104 Assessment 105 Integrated Care Pathways and Care Planning 110 Requesting and Order Communications 111 Results Reporting
The service shall support the clinicians in requesting other investigations. The service shall support clinicians requesting these services in monitoring the progress of the request for analysis, identifying when the results are overdue and what follow up actions are required. 164.13 164.13.1 Diagnosis The service shall enable clinicians to easily capture the details of the diagnosis within patients records. These details should be captured within a comprehensive record for the patient which is capable of being accessed by all authorised care professionals involved in the subsequent care of the person, including general practitioners. Assessment outcomes and actions When people with CHD are referred for specialist secondary care assessment and treatment the service shall ensure that the details of the assessments and care are available to primary care clinicians and others involved in the care of the patients. 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 104 Assessment
164.14 164.14.1
FINAL 1.0a
Page 539 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 107 Care Management 123 eHealth and Clinical Development
The service shall support: electronic notification to GP of outcomes and proposed actions, including proposed treatments to stabilise condition and prescriptions. This may be achieved in different ways, including messaging or provision of access to records. Notification should be consistent with the standard letters defined to support assessment and investigation within rapid access chest pain clinics; and enabling specialist services to access patients longitudinal records to monitor the longer-term success of interventions. Much of this work will be done by GPSIs and specialist nurses working in the community within local clinical networks. The service shall therefore support satellite community based clinics with robust communications between it and the parent DGH. It should include joint access to protocols, records, results and the disease registers and support remote diagnosis, second opinions and quality assurance of echocardiograms performed in the community. interventions -
164.15
Acute surgical revascularisation
164.15.1
The service shall support the planning of surgery including: recording of risk / urgency / priority; the capture of details of decision to admit and procedure; scheduling of pre-admission (catheters angiography etc.); tests
101 User Tools 104 Assessment 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 107 Care Management 108 Scheduling
booking of admission in the case of elective admissions; requesting and booking theatre time
FINAL 1.0a
Page 540 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 109 eBooking 110 Requesting and Order Communications 111 Results Reporting 123 eHealth and Clinical Development 125 Surgical Interventions
and resources; planning post operative and discharge care and support including communication to rehabilitation services; notifying the patient of admission and procedure; planned
receiving patient confirmation (or otherwise) of consent and attendance for surgery; notifying other care involved in care plan; professionals
comparing planned date of surgery with targets and capture reasons for variation; and inclusion of patient choice as some of this work will be undertaken by DTCs, remote centres or private clinics. 107 Care Management 125 Surgical Interventions
164.15.2
The service shall support the admission of patients and the provision of surgery including: the capture of full details of the admission procedures undertaken, clinical support provided (anaesthetics etc.), complications and theatre resources used; compare actual and planned dates of surgery and capture reasons for variation; and enable the planning and provision of post surgical care and support including after discharge.
164.16 164.16.1
Development of a care plan The service shall support clinicians and care professionals in developing care plans for people with CHD or other occlusive arterial disease. In this context the service shall provide: context specific interfaces to access and capture information relevant to the development of the plan; 105 Integrated Care Pathways and Care Planning 106 Clinical Documentation 108 Scheduling 109 eBooking
FINAL 1.0a
Page 541 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 123 eHealth and Clinical Development
decision support based on protocols and / or guidelines to help develop care plan on the basis of information captured; the ability to allocate responsibilities for care inputs to appropriate care professionals and send them notifications; the ability to produce copies of proposed care plan to discuss and agree components and responsibilities with patient including issues regarding modifiable risk factors; the ability to review and revise care plans on a regular basis and following acute events; and
support for referral for specialist rehabilitation and support services. This needs to reflect the growing trend towards a multi-disciplinary approach to care and the need to jointly plan this between hospital and community staff. The service shall support MDT working, joint access to records and virtual case conferences between a range of carers and the patient. 164.17 164.17.1 Implement and monitor care plan The service shall support context specific: access to patient information and protocols to support encounters within plan wherever care is being delivered; recording of details of activities / actions undertaken (dates, durations etc.) and the outcomes of care and progress in achieving care aims including revised assessments; prescribing; and scheduling and booking of screening appointments, annual or more regular reviews and visits etc. 104 Assessment 105 Integrated Care Pathways and Care Planning 108 Scheduling 109 eBooking 113 Prescribing and Pharmacy 123 eHealth and Clinical Development
FINAL 1.0a
Page 542 of 607
ICRS
164.18 164.18.1
Initial Emergency Care The service shall provide decision support at the patients first point of contact (NHS direct, ambulance service, GPs or A&E) to rapidly enable care professionals to identify a patient undergoing AMI and give immediate advice. The service shall enable protocols to ensure that patients are prioritised thrombolysis and aspirin possible opportunity. the use of eligible AMI and receive at the first 104 Assessment 105 Integrated Care Pathways and Care Planning 112 Decision Support 113 Prescribing and Pharmacy 123 eHealth and Clinical Development 154 Ambulance Service
The service shall support automatic collection of national performance improvement data to include call to needle time, door to needle time and run time. 164.18.2 The service shall enable paramedics to record and transmit ECGs and details of other vital signs. The service shall support the transmission of ECGs and other pertinent clinical details for a remote opinion and authorisation of pre-hospital thrombolysis. The location of the opinion will vary between communities but may include ambulance control, A&E, CCU or a remote centralised reading service either NHS or private sector. The service shall furthermore enable the opinion to be made available to the paramedic or other carer attending the patient in a timely manner and enable that opinion and the identity of the person giving it is recorded within the record. 164.18.3 The service shall provide context specific access to details of patients preadmission CHD diagnosis and other conditions, prescriptions and treatment plans, indicating details of GP, consultants and other care professionals providing on-going care and make this available to the carer attending the patient 104 Assessment 105 Integrated Care Pathways and Care Planning 104 Assessment 122 Emergency / Unscheduled Care
FINAL 1.0a
Page 543 of 607
ICRS
including ambulance crews. The service shall automatically feed this data into various audit tools, both locally and nationally to include the Myocardial Infarction National Audit Programme (MINAP) currently managed by the Royal College of Physicians. 164.18.4 The service shall support the capture of details of all elements of emergency treatment provided including events such as cardiac arrest and defibrillation. The service shall automatically feed this data into various audit tools, both locally and nationally to include the Myocardial Infarction National Audit Programme (MINAP) currently managed by the Royal College of Physicians. The service shall support variations to the care pathway depending upon local practices and a changing clinical picture e.g. pre-hospital thrombolysis may lead to direct admission to CCU in places where patients usually pass through A&E. 164.18.5 The service shall enable clinicians and other care professionals providing ongoing care to the patient to be notified of the emergency care incident and outcomes. The service shall support the ambulance service to determine which of a range of potential destination hospitals is most likely to provide optimum care at the time i.e. which are busy, which have CCU beds available and, in some cases, which has primary angioplasty services available. 164.19 164.19.1 Heart Failure People with suspected heart failure should have the cause identified should be offered appropriate investigations (eg ECG, Echocardiography) that will confirm 104 Assessment 108 Scheduling 106 Clinical Documentation 107 Care Management 122 Emergency / Unscheduled Care 104 Assessment 105 Integrated Care Pathways and Care Planning 122 Emergency / Unscheduled Care
FINAL 1.0a
Page 544 of 607
ICRS
The bidders must show that the specific requirements are handled, and the Generic ICRS functions below will give a guide 109 eBooking 105 Integrated care pathways 108 Scheduling 109 eBooking
or refute diagnosis. 164.19.2 Patients with confirmed heart failure should have the cause identified and treatments most likely to relieve symptoms and reduce risk of death should be offered in the community. Cardiac Rehabilitation The service shall support cardiac rehabilitation for all patients who survi ve an acute cardiac event. It shall: ensure that those providing the programme are aware of new cases and are integrated within the discharge planning process; provide decision support and education tools to support people delivering the programme, including patients and their relatives; support cardiac rehabilitation either in the hospital or community setting; and support an audit process to ensure that all who need cardiac rehab have received it. The results of that audit should be available at both practice and clinical network levels.
164.20 164.20.1
Myhealthspace 105 Integrated care pathways and planning 122 emergency and unscheduled care 123 eHealth and Clinical Development
FINAL 1.0a
Page 545 of 607
ICRS
165 - Older people Overview NSFs are not just about collecting data, and this part of the specification will not substitute for each LSP making particular reference to the specific documents available to help in satisfying older people policy and service requirements. It is recognised that every area of specialist activity will have variations in the data it uses and the way it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activity and monitoring, is specific to older people. The NSF for older people sets out a ten-year programme to improve services for older people. The wider older people programme, which includes intermediate and long term care, helping older people stay healthy, and the development of Care Trusts and care direct, aims to extend the years of healthy life and to promote dignity, security and independence in old age. The Information Strategy for Older People is intended to provide the information infrastructure, systems and services required to deliver these programmes. It builds on Information for Health and Information for Social Care to ensure that the implementation of both programmes supports the older people programme. In the first instance, its focus is health and the health and Social Care i terface. Later iterations of the strategy will consider other areas of n service delivery. Within this context, it considers: information for patients, carers and the public; information to facilitate the provision of care; and information for quality improvement, performance management, health improvement and planning.
The aims of the strategy are to: ensure that the implementation of generic information strategies Information for Health and Information for Social Care supports older people services; support and enhance the work programme for services for older people through the development of appropriate information infrastructure, systems and services; and co-ordinate existing work so that local implementation can benefit from good practice.
The prevention of unnecessary hospital admissions and delays in discharge are important outcomes that the modernisation and integration of local services for older people should achieve. The Government plans to introduce financial incentives to ensure that older people should not have to wait to leave hospital when they are ready to do so. These will involve the introduction of a system of reimbursement at the point when responsibility for a patients care transfers from NHS organisations to Social Services. Scope A cornerstone of the Governments policy for the care of Older People is the integration of health and Social Care services, and ICRS must support this integration. In terms of integrated clinical care, mostly to be delivered in the community, this is one of the most ambitious NSFs. ICRS must support health and Social Care professionals, who work together as integrated teams. In some care communities, these care professionals may be employed within a single Care Trust; in others they may remain separately employed by NHS Trusts, PCTs or Social Services. Thus, ICRS solutions must be organisationally independent and support alternative models, enabling all care professionals
FINAL 1.0a
Page 546 of 607
ICRS
involved in integrated care processes to communicate with one another and access Patient Records and associated functionality, with appropriate access control and user authentication safeguards. It is important to recognise that the integrated care processes that must be supported span all care settings. For, example, in many instances the single assessment process should be instigated prior to admissions to hospital for older patients requiring elective surgery or as an important element of rehabilitation planning during the hospital stay of patients admitted as emergencies (for strokes, fractures etc.). ICRS support for integrated care must be patient focused and not setting-based. An important objective for the modernisation of services to Older People is the improvement of patients and their carers access to information and advice. Care Direct has been piloted in a number of areas, and will be implemented on a national basis providing telephone access to information and advice. ICRS solutions within local care communities must be fully integrated with Care Direct. ICRS must enable Health and Social Care Professionals to: access to a single shared Patient Record (logical), which is maintained dynamically as integrated care processes progress; access records, capture information and use consistent processing functionality at the point of contact with the patient, which may include the patients home and at fixed care locations; enable patients and their carers to have access to information within these records, and to contribute to them; apply systematic assessment tools (scales and measurements and the characteristics of patients or responses to problems that are measured or assessed), which may comprise different types of measurement scales; benefit from automatic prompts, alerts and warnings, which may be generated through reference to agreed standard protocols and decision criteria; be supported, as individuals and in managing and supporting teams of care professionals, in workflow management, covering for example the allocation of case responsibilities, co-ordination of assessment inputs and reviews etc; and develop and implement care plans, which comprise of some care inputs towards which the patient will make a financial contribution and for which patient charges may need to be collected; and the requirement to produce schedules of provider payments from these care plans.
Governance and Audit ICRS must support the selection and abstraction of data from Patient Records in order to support both operational management of services and audit, performance management and review of services. ICRS must support the abstraction, aggregation, linkage and analysis of patient level datasets from operational Patient Records. These data are subsets or extracts of the more detailed information that will need to be maintained within Patient Records and shared to support care professionals in direct care processes. Information may need to be assembled relating to the care provided to individual patients within particular time periods. This may be the most appropriate approach in the case of patients who have several conditions or problems which are being treated simultaneously and/or have chronic or longstanding conditions or problems, for which care is required over long time periods. These types of patient form a significant proportion of those older people who should have single assessments. There are difficulties in defining Episodes of care for these groups of patients in relationship to either the duration of the condition or particular treatment events or activities associated with these conditions.
FINAL 1.0a
Page 547 of 607
ICRS
ICRS must also support the definition, selection and abstraction of locally defined datasets. The requirements for older people will be met through the application of the generic functions specified in modules 101 - User Tools-125. It is not intended that any separate systems would be supplied to meet the needs of any condition-specific area. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of older people. In each case, reference has been made to relevant generic modules.
Specific NSF Requirement for older people
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide
165.1
Identifying at risk or vulnerable older people The service shall enable clinicians and care professionals providing care in primary settings to systematically identify older people at risk of or who have had strokes. Similarly the service shall support the systematic identification of older people with other conditions and problems, including mental health (e.g. depression), whose care needs may require regular review. 103 Prevention, Screening and Surveillance 123 eHealth and Clinical Development
165.1.1
165.1.2
The service shall provide context specific support for care professionals to both capture and access those factors that suggest an older person may be at risk of having a stroke. This will include family history, lifestyle factors, the results of tests and investigations and comorbidities, such as hypertension and atrial fibrillation. The service shall support risk measurement tools, which combine and weight a number of such factors to identify relative overall risk. There are a number of such tools that care professionals may choose to use. The service shall support the care professionals in accessing and capturing the full details of the diagnosis and treatment of patients who have already had strokes, their rehabilitation, care and support needs and in developing care plans to address these needs, including reviews.
myhealthspace 104 - Assessment 112 - Decision Support 123 - eHealth and Clinical Development
165.1.3
104 - Assessment 105 - Integrated Care Pathways and Care Planning 123 - eHealth and Clinical Development
FINAL 1.0a
Page 548 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide 104 - Assessment 105 - Integrated Care Pathways and Care Planning
165.1.4
The service shall support standard terms, codes and classifications for capturing diagnoses and treatment details as outlined in Annex 2 of the information strategy for older people. Similar support is required to enable care professionals to capture and access information to identify older people at risk of or with dementia. Support for the screening and review of the needs of at risk or vulnerable people The service shall support regular screening and review processes, of those older people at risk of o with particular r conditions or problems. Managing requests for an assessment to be undertaken The service shall support the initiation of the assessment process and the evaluation of the particular type of assessment, in a range of different circumstances: For example: during or on discharge emergency hospital admission; from
165.1.5
103 Prevention, Screening and Surveillance 123 - eHealth and Clinical Development
165.2
165.2.1
103 Prevention, Screening and Surveillance 123 - eHealth and Clinical Development
165.3
165.3.1
104 Assessment 123 - eHealth and Clinical Development
prior to, during or on discharge from an elective hospital admission; instigated by a care professional (GP, community nurse, therapist, social care professional); following contact arising out of a self referral or a planned contact as part of an ongoing care plan; and/or requested carer. by patient or patients 105 - Integrated Care Pathways and Care Planning 112 - Decision Support
165.3.2
The service shall support care professionals in applying criteria, which may be used to determine whether an assessment is required, and what type or level this should be.
FINAL 1.0a
Page 549 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide 105 - Integrated Care Pathways and Care Planning
165.3.3
If more appropriate, the service shall support care professionals in providing information, relating to a more appropriate service / agency. The service professionals in: shall support care
165.3.4
104 - Assessment
165.3.5
issuing self assessment forms to patients and/or carers; monitoring progress of the individual or carer in completing and returning this form and following up as necessary; and capturing and reviewing the self assessment details. The service shall support the capture of both coded information and structured text. The support provided should minimise the time and effort required to capture this information accurately, and should be supported by prompts and alerts (these may be based on standard protocols and differ for type of problem), pick lists, the retrieval of reference information to help accurately populate certain types of information from partial completion, e.g. address details.
104 - Assessment
165.3.6
The service shall provide automatic search and retrieval to identify possible current and previous involvements. Depending on proposed solutions, this may need to be across several indices and enable retrieval of information in both codified form and as documents from a range of different sources. The service shall provide alerts, where individuals involved in inquiry have previously been identified as at high risk. The service shall enable search and retrieval of information from service directories online, with point and click web style navigation. They should support the automatic production of advice / information and subsequent mailing to
104 - Assessment 106 Clinical Documentation
165.3.7
104 - Assessment 112 - Decision Support Myhealthspace 105 - Integrated Care Pathways and Care Planning
165.3.8
FINAL 1.0a
Page 550 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide 108 Scheduling 109 eBooking
inquirers (note variations).
possible
language
165.3.9
The service shall allow the embedding of material from other systems in scanned or word processed format within assessments, or, as assessments in the wider Single Assessment Process. Coordinating the assessment process The service shall support an individual care professional in acting as coordinator for the assessment process. Coordinators may be from different disciplines depending on the needs of the individual patient and the circumstances in which the assessment is initiated. The service shall enable self-assessment details (or notification of these where inquiry is captured directly into a single shared Patient Record), for subsequent needs assessment by other care professionals. This should be supported by alerts and prompts, where action varies from standard protocols (e.g. different team than suggested by locality, problem). The service shall support the allocation of referrals to care professionals as coordinators, which may involve application of a rules to indicate team members with capacity / appropriate skills to take responsibility. The service shall support the reallocation of responsibilities either on a temporary basis (to ensure targets achieved for individual cases where there are planned absences) or a permanent basis. The service shall support notification of a referral to a team member, with target dates for completion of assessments etc.,
116 Document Management
165.4 165.4.1
104 - Assessment
165.4.2
104 - Assessment
165.4.3
101 - User Tools 112 - Decision Support
165.4.4
FINAL 1.0a
Page 551 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide 112 - Decision Support - Decision Support 124 Information for Secondary Clinical Purposes
based on standard protocols. This should include acknowledgement of receipt of referral. They should enable automatic monitoring of achievement of target completion dates for individual team members and team managers, indicating for example assessments due to be completed within x, x-1 days assessments overdue etc. with a drill down to individual cases. 165.4.5 The service shall also support aggregate monitoring of caseloads (volumes, complexity etc.), performance in meeting targets etc. Assessing a patients needs The Service shall support the capture of both codified information and structured text, which forms an integral part of a patients record, as set out above. The service shall support care professionals in applying systematic assessment tools, which may comprise different types of measurement scales. Assessment is a generic process, which is common to the planning of care for all patients in various settings. The assessment tools (scales and measurements and the characteristics of patients or responses to problems that are measured or assessed) used will differ according to the patients problems or conditions. Changes in the values measured or assessed using these tools are important in determining the effectiveness of both the care of individual patients, but also when abstracted and analysed for classes of patients the overall effectiveness of the care provided The service shall enable care professionals to record levels of disability, dependency using: prompts; simple recording of scores (using a range of input methods); and
101 - User Tools 124 Information for Secondary Clinical Purposes
165.4 165.5.1
104 - Assessment
165.5.2
104 - Assessment 112 - Decision Support 124 Information for Secondary Clinical Purposes
165.5.3
104 - Assessment
FINAL 1.0a
Page 552 of 607
ICRS
165.5.4
through warnings for possible inconsistencies or errors. The Single Assessment Process, Assessment Tools and Scales sets out advice on assessment tools and scales. This lists tools which may be suitable for overview and comprehensive assessment. Some are particularly designed to assess the need for different types of service inputs, e.g. home or residential care. These include: CANE (Camberwell Assessment of Needs of the Elderly) Easy-Care 2002-2005 FACE (Functional Assessment of the Care Environment) Minimum Data Set for Home Care (MDS Home Care) Sheffield Rainbow Assessment Minimum Data Set Residential Assessment Instrument The Royal College of Nursing Assessment Tool for Nursing Older People.
101 - User Tools 104 - Assessment 112 - Decision Support
The service shall be capable of supporting all of these assessment tools. 165.5.5 The service shall support the capture of information obtained from the patient themselves, from carers or relatives, or from other care professionals (who may work in other agencies). This may cover, but is not limited to, the following categories of information: housing and environmental health; communication; personal care and domestic needs; mobility, access and transport; emotional and mental health; physical / medical condition; medication; and/or 104 - Assessment
FINAL 1.0a
Page 553 of 607
ICRS
165.5.6
social relationships and interests. 104 - Assessment
The service shall enable access to documents covering previous assessments. It should be possible to access these from within structured Patient Records, with ability to easily retrieve specific sections within documents. The service shall support the capture of the outcome of the assessment using both a standard consistent terminology and classification, which is codified and as a text description. The service shall enable notification of outcomes of the assessment to other professionals and agencies that have been involved in joint or complex assessments. The service shall support monitoring of time taken to complete assessments (from initial referral, from request for assessment to be undertaken) and compare these actual elapsed times with target or standard times. These may be general or specific and may apply to patients with particular demographic characteristics, domestic circumstances, and level of disability, dependency or capability. The service shall alert care professionals of variations in actual and expected elapse times. Developing a care plan to meet these needs The service shall support the development of care plans by providing access to the prioritised outcomes of patients needs assessment and details of their preferences. The service shall support the development of care plans with overall objectives and targets, which may be expressed and measured in alternative ways. There may also be objectives and
165.5.7
104 - Assessment
165.5.8
104 - Assessment 106 Clinical Documentation
165.5.9
124 Information for Secondary Clinical Purposes
165.6
165.6.1
105 - Integrated Care Pathways and Care Planning
165.6.2
FINAL 1.0a
Page 554 of 607
ICRS
targets relating to the input of specific care professionals. The plan should have milestones and review points. 165.6.3 The service shall provide access to service directories covering possible service providers range of services, capacity, costs, performance, and quality indicators The service shall support care professionals in requesting / ordering the inputs required for care plans. These may be for example equipment and adaptations, or home support provided by independent sector organisations. The service shall support the evaluation of the alternative care plans, including: producing alternative overall costs, for complete plan in case of plans with fixed duration, or for comparable time periods for ongoing plans; and, producing Scores for the likelihood of alternative care plans achieving objectives and for associated risks. 105 - Integrated Care Pathways and Care Planning 105 - Integrated Care Pathways and Care Planning
165.6.4
105 - Integrated Care Pathways and Care Planning 108 Scheduling 109 eBooking 105 - Integrated Care Pathways and Care Planning
165.6.5
165.6.6
The service shall produce details of the ongoing financial implications and affordability of final care plan. The service shall allow aggregate analysis of commitments implied by commissioned care plans, and comparisons with budgets (at team, locality level etc.) to give outturn forecasts of over/under spend. The service shall support the automatic application of rules / criteria for determining financial contributions, and the production of alternative schedules of contributions relating to possible care plans. The service shall allow care professionals to involve patients and their carers in the process of developing the care plan, by providing easy to use ways of accessing
165.6.7
101 - User Tools
165.6.8
105 - Integrated Care Pathways and Care Planning 112 - Decision Support
165.6.9
FINAL 1.0a
Page 555 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide 106 Clinical Documentation
details, including printed copies. The Service shall allow patients, and carers comments and agreements to be recorded. The service shall support the use of electronic methods for the authorisation for care plans. This requires strong user authentication, and detailed audit trails. 165.7 165.7.1 Commissioning and providing care The service shall support the scheduling of care inputs. This may require rules relating to the provision of and/ or to provide care professionals with access to details of: particular patient preferences such as culture, age or sex of staff providing care; staff availability i.e. working days and hours, holidays arranged, training arranged, current commitments; available staff skills and attributes such as age, sex, location and culture; geographic locality information such as travel times; and estimated time taken for set tasks (e.g., shopping, collecting pension, and getting patient up and dressed in the morning).
101 - User Tools 108 Scheduling 109 eBooking 112 - Decision Support
There should be the ability to override the solution offered with an alternative arrangement. 165.7.2 The service shall support the production of staff rotas. 105 - Integrated Care Pathways and Care Planning
165.7.3
The service shall support care professionals through warnings and alerts for staff visiting, for example highlight if the patient or carer is known to be
104 - Assessment 105 - Integrated Care Pathways and Care Planning
FINAL 1.0a
Page 556 of 607
ICRS
confused or violent. 165.7.4 The service shall be provide the information and tools to coincide the times of visits of different care professionals or alternatively provide morning and afternoon cover by specifically avoiding an overlap. The service shall support care professionals in capturing details of activities / actions undertaken (dates, durations etc.) and the outcomes of care and progress in achieving care aims including revised assessments. Reviewing the care plan The service shall support care coordinators in scheduling both planned and unplanned reviews, for example: notifying care professionals involved in complex assessments of the timing of and need for review; scheduling the required actions and appointments, including any review meetings; and following up outstanding actions etc. 105 - Integrated Care Pathways and Care Planning 108 Scheduling 109 eBooking 105 - Integrated Care Pathways and Care Planning 109 eBooking
165.7.5
104 - Assessment
165.8 165.8.1
165.8.2
The service shall support care professionals in comparing the care actually delivered to the care plan / pathway, and in assessing the quality of care provided, outcomes and patients preferences. In the event of an emergency incident, such as a hospital admission, the service shall support the notification of all care professionals involved in the existing care plan to enable them to reschedule or cancel their inputs. Planned or elective admissions of older people
165.8.3
105 - Integrated Care Pathways and Care Planning 106 Clinical Documentation
165.9
165.9.1
For older people requiring elective or planned care, the service shall enable multi-disciplinary and agency assessment
104 - Assessment 105 - Integrated Care Pathways and Care
FINAL 1.0a
Page 557 of 607
ICRS
The bidders must show that the specific requirements are handled, and the generic ICRS functions below will give a guide Planning 107 Care Management
and care planning to commence once an admission date is known.
165.9.2
The service shall provide support for a referral or request for an assessment of the ongoing care needs of a patient to appropriate health and social care professionals, in line with agreed local protocols, which will reflect the planned treatment, the personal characteristics and the household circumstances of the older person (carers etc.). This request may be made by the consultant responsible for admitting the older person or the older persons general practitioner. The referral shall include details of planned admission date and likely discharge date, given the treatment required and characteristics of the older person, assuming no complications occur. The service shall provide support for acknowledgement of the receipt of the request. The service shall provide support for monitoring the progress in undertaking the assessment and developing the care plan, with automatic alerts and warnings of due and overdue actions given agreed local targets and standards, available to both the requestor and the recipient of the request. The service shall enable all care professionals involved in the care plan to be able to access relevant details to their responsibility. This may include care professionals in independent sector service providers. The care plan will be developed in advance of the admission, and solutions must ensure that any variations in planned admission and discharge dates are notified to all those involved in the provision (For example, this may arise out of the death of the patient or the patients admission as an emergency) to enable care inputs to be rescheduled. Similarly any changes in
165.9.3
106 Clinical Documentation 110 Requesting and Order Communications 105 - Integrated Care Pathways and Care Planning
165.9.4
165.9.5
FINAL 1.0a
Page 558 of 607
ICRS
the circumstances of the older person, which may require revisions to the care plan should be highlighted and notified to those responsible for planned care inputs (for example, loss of carer). 165.10 165.10.1 Emergency admissions of older people On admission the service shall enable care professionals to identify any existing and planned care inputs being provided to the older person. For older people admitted as emergencies, the service shall enable multi-disciplinary and agency assessment and care planning to commence as soon as possible after admission, when diagnosis, treatment and likely outcomes become clear. The service shall support the notification other care professionals involved with the admission. This should always include the general practitioner with whom the older person is registered, and other teams (e.g. mental health) who are routinely involved in their care. This notification may trigger an alert that a review of existing care plans is required. The service shall provide support for a referral or request for an assessment of the ongoing care needs of a patient to appropriate health and social care professionals, in line with agreed local protocols, which will reflect the diagnosis, treatment, the personal characteristics and the household circumstances of the older person (carers etc.). This request may be made by the consultant responsible for admitting the older person or by the care co-ordinator/case manager/primary nurse. The referral should include details of likely discharge date and time, given the treatment to be undertaken, likely outcomes and characteristics of the older person, assuming no complications occur. Requests may be made to care 105 - Integrated Care Pathways and Care Planning
165.10.2
104 - Assessment 105 - Integrated Care Pathways and Care Planning 123 - eHealth and Clinical Development
165.10.3
165.10.4
105 - Integrated Care Pathways and Care Planning 106 Clinical Documentation 107 Care Management 108 Scheduling 109 eBooking
FINAL 1.0a
Page 559 of 607
ICRS
professionals within other care communities/agencies, and solutions should enable the responsible care professional and agency to be established. 165.10.5 The service shall provide support for acknowledgement of the receipt of the request. The service shall provide support for monitoring of the progress in undertaking the assessment and developing the care plan, with automatic alerts and warnings of due and overdue actions given agreed local targets and standards, available to both the requestor and the recipient(s) of the request. The support required for assessment and care planning processes may involve an initial assessment of needs and risks, to identify whether the patient should be discharged home or to another intermediate of non-acute setting, where a further complex assessment should be undertaken. The service shall enable all care professionals involved in the care plan to be able to access relevant details to their responsibility. This may include care professionals in independent sector service providers. 165.10.8 The care plan will be developed in advance of discharge, and the service shall ensure that any variations in expected discharge dates are notified to all those involved in the provision to enable care inputs to be rescheduled. Identification of discharge delays and reimbursement required The service shall enable the progress of development of the care plan to be monitored, and the capture of key dates, for example: 105 - Integrated Care Pathways and Care Planning 105 - Integrated Care Pathways and Care Planning 105 - Integrated Care Pathways and Care Planning
165.10.6
104 - Assessment 105 - Integrated Care Pathways and Care Planning
165.10.7
104 - Assessment 105 - Integrated Care Pathways and Care Planning 107 Care Management 123 - eHealth and Clinical Development
165.11
165.11.1
FINAL 1.0a
Page 560 of 607
ICRS
date decided to admit (electives); planned admission date(s) (electives); planned discharge date(s) (electives and emergencies); date of completion of care plan (electives and emergencies); dates care plans revised / amended (both); actual date of admission (both); date patient ready and safe to be transferred / discharged (both) solutions should enable this date to be captured as a result of the ongoing support for monitoring the status of the patient; and/or actual date of discharge (both).
The capture of these dates will enable the service to calculate and reimbursement due at standard tariffs. The service shall also enable the reasons for delay to be identified by reference to those components of care plans that were not available / in place at the time the patient was ready and safe for transfer.
166 - CHILDRENS SERVICES Overview The Governments vision for the Care of Children is outlined in the National Service Framework for Children, which will be published during winter 2003/04. The Governments vision for childrens services overall is to be set out in a green paper, due in September 2003. In preparation, the following is an overview of the requirements that ICRS will need to support in order that the standards can be met. The Childrens NSF is being developed in eight key areas: hospital services; maternity; healthy children and young people; disabled children; mental health and psychological well being of children and young people; children in special circumstances; the ill child; and
FINAL 1.0a
Page 561 of 607
ICRS
medicines.
These areas will serve to focus attention on several key issues pertinent to the ICRS. Significant in this context, will be the enabling of health, Social Care and other agencies to: access shared Patient records; utilise "common datasets" to plan and monitor services; share information in a secure and confidential environment; and supporting the requirements of the Children Act 1989 (particularly sections 17 and 47).
The standards outlined in the Childrens NSF stress the importance of seeing children from a holistic perspective. In this context, it will address the needs of children from pre-birth to their nineteenth birthday and also deal with the issues relating to the transition into adult life (e.g., age of consent, Gillick competency etc). Consequently, ICRS will need to, where appropriate and agreed, link into other non-health systems relating to children and to define the nature and scope of the relevant interfaces. The design of the underpinning functionality of the ICRS in relation to its childrens module will therefore need to be shaped and referenced by dependence upon maternity systems, child health systems and Primary Care systems with some of the more specialised systems, for example: identification, referral and tracking systems (IRT) required to support local preventative strategies; * integrated childrens systems (ICS) required to support assessment frameworks covering needs, risk, vulnerability, social exclusion and health status and supporting the version 3.0 of the Childrens Social Services Core Information Requirements; systems designed around "looked after children" and children in special circumstances and supporting Child Protection Registers and family records (as used by Health Visitors etc.) where appropriate; and child and adolescent mental health systems.
The hospital standard has been published in advance of the rest of the NSF in order to meet the commitment made in the governments response to Learning from Bristol and consequently it is important to recognise that as the other standards are published the new requirements will be identified. It is essential that the ICRS must enable health, social, education and other agencies to have access to a single shared record for each child . Scope ICRS must support local communities in providing a full range of services to enable children to meet their best potential. Achieving this goal necessarily brings into focus the complexity of the journey children must take through life, as both a healthy individual and as a user of health and Social Care services. From birth, there will be a variety of different agencies and programmes in the community concerned with children and their development, thereby involving a range of professionals (e.g., midwives, Health Visitors, GPs, school nurses, teachers, etc.) involved in assessing childrens well being and in providing a service. The ICRS will be pivotal in ensuring children experience a seamless web of care, treatment and support as they move through these services. Accordingly ICRS must reflect the complexity of these processes by taking into account that integrated teams will be multi-disciplinary and as such will operate in several different but inter-related environments. The success with which ICRS supports this service configuration will depend on several factors, not least its:
FINAL 1.0a
Page 562 of 607
ICRS
organisational independence; design around the normal development of the child through care pathways and ability to determine the clear information requirements thereof including a facility to track all relevant aspects of growth and development; support for good communication facilities between services and across functions; support for intelligent use of information in an inter-agency and "cross cutting" context; support for data exchange using national accredited communication standards; and implementation of control mechanisms vis--vis record access and information sharing.
The ICRS must support the Childrens NSF standards by ensuring that, as a minimum, its functionality is designed around and supports: multiple and secure access to shared electronic records; access to administration and demographic details of a child or young person; intelligent "alerting and prompting adapted in relation to the age and size of the child"; workflow management; care planning including assessment and outcomes data capture tools; screening, immunisation and surveillance programme ; lifestyle modification programmes and health improvements initiatives; management of referrals across all services; national coding standards and classifications; information requirements around parent/guardian/carer involvements; full range of scheduling and booking appointments; comprehensive Audit Trails; specialist services such as Child and Family services; targeted services such as Sure Start; governance around patient consent including copying of letters; and consultation of a young patient by a doctor who is not their own GP and for data from this consultation to be invisible to the patients registered GP.
The importance of administrating childrens services in a co-ordinated and integrated environment has been given further impetus by the concept of Childrens Trusts and their exclusive focus on the needs of children and young people. Use of information in this context is significant and the ICRS will need to be able to support evidence-based service delivery, with special emphasis on modernisation and re-design. The ICRS will therefore need to ensure that: data can be extracted from records in a structured and accessible format to support robust and intelligent planning; and that tools are available to: undertake information modelling and trend analysis, especially around determinants of risk and social exclusion; e.g., child inequality; and support organisational and corporate requirements around performance, commissioning, statutory and national reporting.
ICRS must allow capture of accurate coded information and structured text using both standard and consistent terminologies and classifications. Governance and Audit ICRS must make sure that information can be:
FINAL 1.0a
Page 563 of 607
ICRS
compiled and assembled on a pan-community basis and in a format that allows integration with other data sources; aggregated using a number of different denominators eg: PCT, SHA educational catchment area etc for a variety of both epidemiological purposes, planning purposes, screening programmes, and monitoring (e.g., of referral rates, waiting lists etc.); produced which can support "cross cutting" analyses and performance monitoring; collected and derived to support health needs assessments and other health improvement initiatives around childrens health promotion; collected to support clinical governance and other quality information needed for benchmarking and performance assessment frameworks.
To support this, ICRS must: support the selection and abstraction of data from Patient Records in order to support operational management of service and audit, performance management and review of service; support the monitoring of quality targets that are in place nationally and locally; support Audit Trails; be able to monitor referral rates and waiting lists; be able to capture the whole range of statistical returns; and support definitions, selection and abstraction of national and local defined datasets.
The main NSF is due for publication winter 2003/04, and could be the first NSF to base its modernisation strategy on IT. For information see the URL, <http://www.doh.gov.uk/nsf/children.htm>. The first part of the childrens NSF (and the only one so far published) sets out the standard for care for children and young people when they are in hospital. The requirements for this NSF will be met through the application of the generic functions specified in previous sections (101 to 125). It is not forseen that systems dedicated to this NSF will be required. Each bidder shall describe how their proposals for generic functions will be applied to meet the requirements below, and must identify any specific additional features required to support the needs of children. In each case, reference has been made to relevant generic modules.
166.1
Involvement of children and young people in the planning and delivery of care The NSF emphasises the close involvement of parents and children in the planning and carrying out of care. The service shall reflect this in application of specific generic functionality (which has been defined in previous sections) and in particular: the care planning, programmes function interact with parents partners equal to the pathways and shall be able to and patients as professionals in 101 User tools 105 Integrated Care Pathways and Care Planning
166.1.1
FINAL 1.0a
Page 564 of 607
ICRS
the planning and delivery of care. The service shall incorporate the concept of team working in management of planned care identifying both parents and children as members of the team. The service shall support the presentation of information which reflects the developmental and cultural background of the person to whom it is directed. This includes patient histories, general information on specific conditions and interactive functions (e.g., care pathways, system generated alerts).
166.2 166.2.1
Coordinated delivery of care The NSF recommends that hospital stays should be kept to a minimum through the coordinated delivery of care. The service shall facilitate this through the provision of timely and relevant information, and through boundary-crossing care pathways in which parents and patients can participate as equals. The service shall support the provision of locally based care in the community and at home, supported by remote links to specialist care and support in secondary and tertiary care centres. 105 Integrated Care Pathways and Care Planning
166.2.2
105 Integrated Care Pathways and Care Planning 109 eBooking 112 Decision Support 123 - eHealth and Clinical Development 105 - Integrated Care Pathways and Care Planning
166.2.3
Children are particularly likely to have complex disorders that cross specialty boundaries. The service shall support this through the provision of multidisciplinary care pathways, shared care and support for managed care networks. Evidence-based practice The importance of evidence-based practice is highlighted by the NSF the service shall support clinical audit and clinical decision-making, including electronic prescribing and decision support systems appropriate to paediatrics.
166.3 166.3.1
112 Decision Support 113 Prescribing and Pharmacy
FINAL 1.0a
Page 565 of 607
ICRS
166.4 166.4.1
Children with disabilities The service shall support the provision of patient histories and summaries, subject to access permissions, to the wide range of health care professionals involved in the care of children, specifically children with disabilities who come into contact with a wide range of care professionals. Maternity The service shall support the provision of care to children during their birth and neonatal care. 118 Maternity 106 Clinical Documentation
166.5 166.5.1
FINAL 1.0a
Page 566 of 607
ICRS
167 - Renal services Overview NSFs are not just about collecting data, and this part of the specification will not substitute for each LSP making particular reference to the specific documents available to help in satisfying the policy and service requirements for the prevention of renal disease and management of people with renal failure. It is recognised that every area of specialist activity will have variations in the data it uses and the way it operates the basic primary clinical (and other) activity. This part of the specification identifies that which, in terms of overall activity and monitoring, is specific to people with renal disease, particularly those with renal failure. In February 2001, the Secretary of State announced his intention to establish a new set of national standards to improve services for 30,000 kidney patients. The incidence and prevalence of kidney failure is increasing steadily, and as such there is a real need to address issues of prevention and capacity to reduce incidence and increase choice and treatment options. This will be addressed through a number of processes: the development of improved preventative strategies based around well established risk factors and interventions. reduction in the variation in treatment rates and quality of service, including referral to nephrologists and the development of care plans. provision of sufficient capacity to ensure that patients consistently receive optimal care (i.e. choice of treatment and frequency of dialysis) optimization of access to and outcome of renal transplantation.
The new Renal Services NSF will be developed with the help of health and social care professionals and managers, patients, carers, partner, agencies and other advocates. It will be the blueprint for national standards and services that will improve treatment and care for the 30,000 patients in the UK on dialysis or living with a kidney transplant. As with other published NSFs the Renal Services NSF standards will be supported by an information strategy, which will build on work already underway for existing national service frameworks to ensure that that the specific renal issues can be addressed in an appropriate manner. This will include (through close collaboration with the Renal Registry and UKT) the development of a nationally approved dataset. The dataset is expected to incorporate the two existing data sets and be developed to include those elements required that are not within the scope of the two current collections. Renal Services NSF is expected to be published later this year. Further information can be found at the URL, <http://www.doh.gov.uk/nsf/renal.htm>.
Scope
The Renal NSF has been developed in 4 modules to consider the whole patient journey. This starts with those at risk because of congenital, acquired or inherited renal disease or risk factors, through the process of diagnosis, progression to renal failure, dialysis and transplantation and supported care and decisions at the end of life. Module 1 This is concerned with haemodialysis and peritoneal dialysis and includes the year prior to the start of renal replacement therapy and issues surrounding appropriate and timely access surgery.
FINAL 1.0a
Page 567 of 607
ICRS
Module 2 This is concerned with maximising the benefits of transplantation, and includes key issues relating to live and cadaveric donors. Some donor issues are dealt with in the Transplant Framework, published by the DoH. Module 3 This module is concerned with:
identification of people at risk of renal failure because of previously identified renal disease or congenital, inherited or acquired conditions predisposing to renal disease and renal disease. detection of early progressive renal disease and early signs of renal failure by detection of proteinuria, hypertension or reduced or falling GFR. prevention of renal failure by evidence based management of those identified. Lifestyle choices that reduce risk and increase longevity.
This module also addresses acute renal failure which is an important source of morbidity and mortality and also provides a source of patients who do not recover and therefore have unplanned acute onset chronic renal failure. Module 4 End of life care is an important choice for people with ERF, a difficult condition from which there can be no recovery. Planned and supported care at the end of life is important component of the services provided. It should be noted that, at the time of publication of the OBS, Modules 1 and 2 are further advanced than Modules 3 and 4. As a consequence, the renal services requirements of ICRS address the needs within primary and secondary care settings. Further requirements relating to primary and palliative care settings are yet to be articulated. Governance and audit The ICRS spine and LSP must provide a facility for the direct care of the patient with renal disease, in primary, secondary and tertiary care and provide the functionality to deliver data for secondary purposes: For the direct care of patients with renal failure the ICRS will ensure that the system will: provide a continuous lifelong record of the patients history, care, discussions and wellbeing; Ability to support serial online biochemical and other tests, X-rays and biopsies; provide facilities for data transformation for assessing progress and adequacy of care (e.g., estimated GFR using the Cockroft and Galt formula or KT/V for dialysis adequacy); enable the patient and health professionals to participate in the development and use of a personal care plan which enables the patient to have access to their own records and participate in their own management and joint decisions; share information appropriately between health sectors, members of the multidisciplinary team and other specialists in an accurate and timely way with due regard to confidentiality and with the patients consent; provide the facility for prescribing information for patients with various levels of impaired renal function and with renal transplants; enable patients waiting for a transplant to access their status on the transplant list; provide decision support based on evidence; provide access to the knowledge base for patients and health professionals; functionality for decision support to clinicians at the point of care informed by evidence-based information such as that developed by the NeLH; information to monitor the standards of the Renal Association, the British Transplantation Society and other relevant professional bodies; and
FINAL 1.0a
Page 568 of 607
ICRS
information to monitor the standards outlined in the Renal National Service Framework for renal disease and other NSFs such as Diabetes, CHD and Childrens & Maternity Services when published.
For the management of donors there should be facilities to support: (For live donors) the needs of live donors as patients and organ donors; the ability of live donors to see the results of their tests and participate in shared decision making; the ability to provide statutory information about live donation to UK Transplant; the ability to provide follow up of the donor;
(for cadaveric donors) the needs of cadaveric donors, both heart beating and non-heart beating, including records that continue to function and are accessible after the death of the donor; functionality to support links for health professionals to the organ donor register in order to establish the status and wishes of a potential donor; functionality to enable health professionals to view the medical records of potential donors, both non-heart beating and heart beating donors to inform decisions about proceeding with organ donation; functionality to support UK Transplant in the process of organ allocation and statutory duties related to organ donation; functionality to enable health professionals to view the records of cadaveric kidney donors or if the recipient has a subsequent problem or to research newly identified problems and to identify the recipients if the donor is later found to have an unexpected problem (e.g. cancer found at post mortem or CJD); enable information to be transferred from donor to recipients and from one recipient to others from a common donor, when required, with appropriate levels of confidentiality; provide information required for organ allocation through UK Transplant; and
(For healthy people) enable those who wish, to register on the organ donor register.
Data for secondary purposes: In addition the data required for secondary purposes (epidemiology, incidence, prevalence, activity, outcome, treatment modalities, audit, benchmarking, management, clinical governance, planning commissioning and research) must be derived from the Patient Record. This must include: Information about patients with renal failure: information about patients with renal failure in primary secondary and tertiary care; data required for the renal registry and other key stakeholders. (The details of the information required will be informed by a review of information to be undertaken by the NHSIA and commissioned by the DoH); information on the waiting times and outcome of transplantation;
Information about donated organs:
FINAL 1.0a
Page 569 of 607
ICRS
information required by UK transplant for statutory duties; information required to monitor the outcome of renal transplantation in relation to the type of organ, its condition and transfer; information about the organ allocation and transplantation process;
Information about donors: information on live donors, including follow up; and information about cadaveric donors.
FINAL 1.0a
Page 570 of 607
ICRS
168 - LONG TERM CONDITIONS Overview On 28 February 2001, the Secretary of State announced the development of a National Service Framework for Long Term Conditions. The NSF will have a particular focus on the needs of people with neurological disease and brain and spinal injury and will consider some of the generic issues of relevance to a wide range of people with long-term conditions and disabilities. The Authority has appointed an external reference group (ERG) which will oversee the development of the NSF. Membership of the ERG is drawn from patients and carers, health and Social Care professionals and managers, and voluntary organisations. The NSF for Long Term Conditions will be published in 2004 for implementation in 2005. Further information can be found at the URL, <http://www.doh.gov.uk/nsf/longterm.htm>.
FINAL 1.0a
Page 571 of 607
ICRS
SERVICE DELIVERY REQUIREMENTS 900 SERVICE DELIVERY REQUIREMENTS Overview The purpose of this section is to provide bidders for LSPs roles with a specification for the range of services required to support the local implementation of the NPFIT, including the local delivery of ICRS, and eBooking. LSPs will have a vital role in ensuring the effective and efficient operational delivery of these services at a local level. Key responsibilities for LSPs are local implementation, testing, training and operational support. Integration with the Spine, eBooking, and participation in the future development of the NPFIT, and working in close conjunction with the NASPs, will also be essential requirements. In line with the NPFIT, it is expected that LSPs will support interoperability between Clusters and work closely with other LSPs and with NISPs and NASPs to deliver integrated services. Scope Components The general user requirements of this module are to: define the service to be delivered by each LSP associated with the implementation of ICRS, eBooking and other local aspects of the NPFIT; and highlight the specific requirements to be met by the LSP for each service.
Exclusions These requirements exclude services relating to national services delivered by NASPs, including the ICRS NASP, and NISPs.
Delivery expectations Minimum level to be achieved by December 2004 For two Clusters to be designated by the Authority, LSPs are expected to have in place services that support: the local implementation of ICRS (incorporating the Phase 1 functionality outlined in Part II.1 of this OBS) and eBooking (as set out in the eBooking OBS); the integration of the LSP Services with the National Services, including the Spine and the national eBooking service, through interfaces and data structures which conform to Authority requirements; where appropriate, a management service for existing legacy systems or integration of new applications with retained systems; where required at a local level, an infrastructure management service, which may involve taking over elements of the existing local infrastructure or installing new or replacement infrastructure components; a Help Desk Service for all users across the health community; and business process re-engineering support.
FINAL 1.0a
Page 572 of 607
ICRS
Ultimately, LSPs will be responsible for the delivery of a full range of IT services in a specified health community. The evolving business requirements at a Cluster level will drive the development of services, whilst national requirements and standards will require interoperability and common data structures. Overview requirements Requirement 900.1 Overview Each LSP is required to provide a range of services to support the local implementation of ICRS, eBooking and other locally-delivered services forming part of the NPFIT. Key components across the whole life of the project will be: programme and project management; testing and acceptance; implementation services; training; design and development; business change management; new systems and services; operational support; integration and data output services; legacy management; infrastructure services; transfer of personnel; and change control. Authoritys Responsibilities Required response Each bidder shall confirm its ability to deliver the services described and respond to the detailed requirements section for each of these services.
900.2
For each service area, each bidder shall describe the responsibilities that it would expect to be assumed by the Authority.
Detailed requirements 910 - PROGRAMME AND PROJE CT MANAGEMENT Requirement 910.1 Overview High quality programme and project management will be an essential requirement for delivery of LSP Services as part of the NPFIT, including integration with the national services delivered by NASPs and NISPs, as well as with LSP Services delivered by other LSPs. Required response Each bidder shall describe its overall approach to programme and project management and programme governance. Each bidder shall describe how it would establish effective arrangements for working with the NHS, locally and nationally, and
FINAL 1.0a
Page 573 of 607
ICRS
Requirement
Required response with other LSPs, NASPs and NISPs.
910.2 910.2.1
Appointment of programme/project managers For each care community, the LSP shall appoint a programme manager with operational responsibility for service delivery. Due to the essential requirement for high calibre project management, this appointment shall be a joint decision of both the LSP and the NHS. The LSP programme manager and supporting project managers shall possess the necessary skills and experience to manage the local implementation of services and engage with the NISPs, NASPs, other LSPs and NHS stakeholders. Each health community shall have the right to request that the LSP programme manager or other LSP project managers involved in the health community project be replaced. This right will not be unreasonably exercised. Role of programme manager The programme manager shall be operationally responsible for all the LSP-contracted deliverables and management of any LSP implementation staff and subproject managers. The programme manager shall manage the LSP relationship with the NASPs and will ensure local conformance to national standards and requirements as set by the NASPs and the Authority. Each bidder shall describe how it would discharge this responsibility. Each bidder shall indicate its agreement to this requirement.
910.2.2
Provide indicative experience of appropriate staff, including CVs, etc.
910.2.3
Confirm that agreement to such a request will not be unreasonably withheld.
910.3 910.3.1
910.3.2
Each bidder shall describe its proposed approach to managing the relationship with NASPs. In particular, each bidder shall describe the contractual mechanisms it would propose. Each bidder shall indicate its agreement to this requirement and how it would meet it.
910.3.3
The programme manager shall be the primary LSP point of contact regarding all NPFIT matters for both staff within the health community and those working on National Application and infrastructure services. The programme manager shall work closely with the NISPs and NASPs in ensuring that common data structures, interoperability and standards are applied consistently across local implementations of the ICRS, eBooking and other relevant projects. The programme manager shall ensure that project deadlines are met, resources are allocated appropriately, and quality procedures and
910.3.4
Each bidder shall indicate its agreement to this requirement and how it would meet it.
910.3.5
Each bidder shall describe the arrangements it proposes to ensure the accountability of the LSP for delivery of programme
FINAL 1.0a
Page 574 of 607
ICRS
Requirement recommendations are implemented. 910.4 910.4.1 Project management methodology and governance The LSP shall deliver the requirements of this OBS to industry standard project and quality management methodologies.
Required response objectives in line with the contract.
Each bidder shall describe its project management methodology and how it compares with the PRINCE II methodology used by the NHS. Each bidder shall outline any relevant quality management processes utilised. Each bidder shall indicate its acceptance of these reporting arrangements.
910.4.2
The programme manager shall attend any programme board or other programme governance forum established by the health community. They shall be accountable to the programme board for the LSP deliverables and shall provide progress updates against the agreed project plans. The programme manager shall attend any programme governance forum established by the NASPs to confirm local application of all required national standards. Project planning, monitoring and reporting The LSP shall be responsible for the production, monitoring and reporting of the overall project plan for the health community. Project plans shall define overall timescales and identify core project phases, milestones and tasks. The programme manager would be expected to agree these plans with the health community project co-ordinator prior to publication. The LSP shall work closely with the local project team and the Authority to produce a project initiation document for the local project. The LSP shall produce a quality plan, defining the standards, procedures and methods to be used in the implementation of the LSP Services. The programme manager shall prepare regular progress reports and end-stage reports and highlight any variance from the agreed project plans. The programme manager shall maintain and manage issue logs. Where required, outstanding issues will be escalated for resolution at any programme board o r other project governance forum.
910.4.3
Each bidder shall describe its approach to working with the NASPs.
910.5 910.5.1
Each bidder shall describe its approach to project planning. Each bidder shall indicate its choice of project planning software and its approach to managing the plans.
910.5.2
Outline the typical structure headings to be incorporated within a PID. Outline the typical structure headings to be incorporated within a quality plan. Provide examples of its project reporting approach.
910.5.3
910.5.4
910.5.5
Each bidder shall describe its proposed approach to logging and managing the resolution of issues.
FINAL 1.0a
Page 575 of 607
ICRS
Requirement 910.6 910.6.1 Communications The LSP shall be responsible for ensuring effective communications and co-ordination with o ther parts of the NPFIT, including national and local project teams. The LSP shall be responsible for ensuring appropriate top down communications are in place to keep NHS stakeholders informed and engaged with the local programme. The LSP shall ensure that appropriate communication links are maintained with other LSPs/local projects and the NASPs and NISPS. The LSP shall establish effective communications across all health community project groups and teams.
Required response
Each bidder shall describe its overall approach to communications. Suggest how this might be best achieved.
910.6.2
910.6.3
Suggest how this might be best achieved.
910.6.4
Provide examples of how effective internal communications might be established within the health community project.
910.7 910.7.1
Risk management The LSP shall undertake a risk analysis to identify and quantify areas of the project that could be exposed to risk of failure, delay or otherwise. The LSP shall produce a risk register highlighting key risks, probability of occurrence, impact level and an overall risk factor. Regular assessments of the risk register shall be undertaken by the LSP and strategies proposed to mitigate the risks. Each bidder shall describe its overall approach to risk analysis and risk management, and how it will work with the Authority to mitigate risks.
FINAL 1.0a
Page 576 of 607
ICRS
920 - TESTING AND ACCEPTANCE Requirement 920.1 Overview Once selected, each LSP will be expected to demonstrate that the IT service components developed or delivered by it are suitable for operational use within the health community. This will be achieved through the joint development of acceptance criteria and a programme of testing and local user trials. The Authority shall reserve rights in relation to defects. 920.2 920.2.1 The Acceptance Process The LSP shall propose an acceptance process that ensures that each deliverable and each service is delivered for operational use in accordance with the service specifications and service level agreements. Acceptance and sign-off shall in each case be without prejudice to the rights or remedies of the Authority and shall not have any legal effect to the contrary. 920.2.2 The acceptance process shall be completed in stages covering: design of the local solution; system testing by the LSP of any developed software; local integration of data from existing legacy systems; local integration of data between new applications; and data exchange and integration with National Applications. Each bidder shall indicate how might this be best achieved. Outline its approach to the testing and acceptance process for each of these stages. Each bidder shall describe how it proposes to achieve this. Required response Each bidder shall describe its overall approach to testing and acceptance.
920.2.3
The LSP shall obtain a sign off approval from the Authority confirming user acceptance for each stage. This shall be obtained prior to commencing the next stage. The LSP shall co-ordinate the testing and acceptance process ensuring the participation of users throughout each stage. The testing and user-acceptance process shall be clearly documented by the LSP in a systems test plan for approval by the programme board.
920.2.4
Each bidder shall indicate how it will secure user participation.
920.2.5
Each bidder shall describe the characteristics of any system test plan it would prepare.
FINAL 1.0a
Page 577 of 607
ICRS
Requirement 920.3 920.3.1 Acceptance Criteria The LSP shall propose acceptance criteria to establish whether the relevant service specifications are being met. These criteria shall include but not be limited to the functionality, availability and performance of the service. The Authority shall approve in advance the acceptance criteria for each major implementation milestone. The LSP shall ensure involvement of the health community and, for any design specifications, the NDA in defining the acceptance criteria. Acceptance Tests The LSP shall agree with the health community an acceptance testing script that can be used to verify the operation of the service. The script shall include test procedures and expected results. The Authority shall have approved the test scripts prior to the commencement of acceptance testing. Where relevant (e.g., in respect of ICRS) the LSP shall test any initial system design and architecture by seeking acceptance and approval from the NDA.
Required response
Indicate examples of acceptance criteria used in earlier projects.
920.3.2
Outline its approach to obtaining client ownership of the acceptance criteria.
920.4 920.4.1
Provide a template for acceptance testing.
920.4.2
Each bidder shall describe how it would propose to involve the NDA in testing the initial system design and architecture. Provide details of internal testing and quality standards.
920.4.3
Any newly developed software shall be tested by the LSP then released to the Authority for user acceptance testing. The upload of data from existing legacy systems and associated interface routines shall be tested to the satisfaction of the Authority. Local integration testing shall be required for the identified movement of data between: existing legacy systems and new applications; and multiple new applications.
920.4.4
Outline its approach to data upload from existing systems.
920.4.5
Outline its approach to integration testing.
920.4. 6
Where appropriate (e.g., where a health community crosses boundaries served by different LSPs), testing of data integration between applications developed by different Bidders shall be required to demonstrate the interoperability of proposed solutions. Integration testing shall be undertaken in conjunction with the NASPs (including those extant National
Each bidder shall describe its proposed approach to testing data integration across LSP boundaries.
920.4.7
Each bidder shall describe its proposed approach to integration
FINAL 1.0a
Page 578 of 607
ICRS
Requirement systems such as the PPA systems) as required by the Authority. In respect of ICRS, this will include verification of the interchange of data with the Spine. In respect of eBooking, this will involve testing of connections and technical operation of the national service. This process will be led by the relevant NASP and will require joint working with both the NASP and other LSPs. 920.4.8 The LSP shall ensure that a test dataset is available for user testing within the testing environment, which will represent a simulated NHS IT infrastructure environment. The LSP shall assist users in the performance of tests and logging of issues where results fail to satisfy acceptance criteria. The acceptance tests shall include proposed security solutions and their effectiveness. System updates shall be acceptance-tested prior to implementation and appropriate regression tests undertaken to ensure an ability to restore systems to an earlier version if required.
Required response testing with NASPs and operation with other LSPs. co-
Outline the range of datasets required for an effective acceptance testing process.
920.4.9
Each bidder shall describe how it proposes to involve users in the acceptance testing process. Each bidder shall describe how it proposes to achieve this. Each bidder shall describe its approach to acceptance testing and regression testing for all subsequent updates.
920.4.10
920.4.11
920.5 920.5.1
Sandpit The LSP shall provide a Sandpit facility to support testing and acceptance processes and: the environment will include sufficient network and systems to provide a realistic simulation of the necessary process flows required by each test and to measure these; the sandpit will maintain current versions of all key systems by virtue of the mandatory requirement to notify configuration changes and complete regression testing in the sandpit; simply inter-operability testing may make use of stubs to simulate key systems that are not yet operational; LSP will provide everything that they require to prove their solution (e.g. hardware, software, technical and business resources);
FINAL 1.0a
Page 579 of 607
ICRS
as systems complete acceptance they will be retained in the sandpit to provide a reference against which to test future systems; and Legacy systems will be included in the sandpit process where necessary - with physical copies included if appropriate.
FINAL 1.0a
Page 580 of 607
ICRS
930 - IMPLEMENTATION SERVICES Requirement 930.1 Overview LSPs will be responsible for implementing ICRS, eBooking and other services at the Cluster level. It will be essential that, once agreed, the services are implemented in a timely and efficient manner. LSPs will be expected to work closely with the Authority to develop local implementation plans. 930.2 930.2.1 Implementation Planning Bidders shall work closely with the Authority to produce high-level implementation plans for LSP Services, including the Cluster-level requirements for ICRS and eBooking. The plans will be used to manage and control the overall implementation of the services and shall provide confidence to all parties of the effort and commitment needed to deliver the LSP Services. The implementation plan shall detail the delivery stages, resources, tasks and responsibilities of all parties for the delivery of the local ICRS, eBooking and other services. Each LSP shall produce an implementation plan covering all the key stages of implementation, including the following elements as a minimum: programme initiation and set-up; assessment of local readiness source data and systems, data quality, local infrastructure, etc; solution design and build (where relevant); acceptance testing (including integration testing); new/upgraded infrastructure; data take-on from existing systems; roll-out of the solution across the health community; data quality and standards; and integration with national services. Each bidder shall describe its approach to implementation planning. Each bidder shall describe its overall approach to implementing the LSP Services, and how it would work with local health communities to achieve this. Required response
930.2.2
Provide an indicative outline implementation plan, identifying all the key stages involved in implementing the LSP Services. As a minimum, this should cover the local implementat ions of ICRS and eBooking.
930.2.3
Bidders shall ensure that the Authority is enabled to supervise the development of implementation plans.
Indicate how this may be best achieved. Each bidder shall describe how it would propose to achieve this balance.
930.2.4
Bidders shall balance the national requirement for a standard approach (particularly around services such as eBooking) with the local need to implement within a diverse set of organisations. Bidders shall supply sufficient competent resource to assist the Authority in the production of implementation
930.2.5
Each bidder shall give an indication of the resources it has available to support
FINAL 1.0a
Page 581 of 607
ICRS
Requirement plans. 930.3 930.3.1 Phasing The ICRS functionality is defined in Part II.1 of this OBS, along with minimum delivery expectations at the conclusion of Phase 1 in December 2004. The phasing-in of this functionality shall be clearly defined by LSPs within the implementation plans. Data Take-on and Quality Bidders shall review and document the various data sources for the proposed services, including ICRS and eBooking. Bidders shall also be responsible for whatever steps are required to improve data quality prior to data take-on for the new services. As a minimum, the possible sources of data will include: interfaces to existing operational legacy systems; interfaces to newly implemented operational systems; and manual or paper-based records.
Required response implementation planning.
Using the functional specifications in Part II, provide a Gantt chart showing an indicative phasing of the required functionality.
930.4 930.4.1
Each bidder shall outline its proposed approach to assuring the quality of existing data prior to take-on.
930.4.2
Bidders shall take responsibility for managing the take on of data to support the new services, including historical data. The data quality and standards defined by NPFIT shall be met to ensure integration with the Spine and other national services and LSP Services. Timescales Bidders shall contractually commit to the agreed timescales. The timescales for the full implementation of the LSP Service shall be agreed during contract negotiations.
Each bidder shall describe its proposed approach to data takeon. Each bidder shall describe how it would achieve this.
930.4.3
930.5 930.5.1
Each bidder shall indicate its understanding of the implementation timescales and shall describe how it would take responsibility for delivering to agreed timescales. Each bidder shall describe its approach to the adoption of standards and confirm its agreement to this. Each bidder shall describe how it would work with NASPs and the Authority to achieve this.
930.5.2
As part of the above, Bidders shall commit to timescales for the full implementation of standards, after they have been determined by NPFIT.
930.5.3
Bidders shall ensure that the local implementation plans are aligned with the timescales for data integration set by the Authority and NASPs.
FINAL 1.0a
Page 582 of 607
ICRS
Requirement 930.6 930.6.1 Local Ownership Bidders shall ensure that the Authority is enabled to supervise the development of the local implementation plans. Bidders shall balance the national requirement for a standard approach with local requirements to implement the services across diverse sites within the health community. Bidders shall establish and manage implementation teams within the health community and ensure engagement with the Trusts and other healthcare sites across the health community. Relationship with National Application Service Providers The NASPs will have a lead role in ensuring that local implementations: apply consistent approaches to the design, exchange and integration of data; conform to the technical and data standards identified nationally; and allow interoperability across Clusters.
Required response
930.6.2
Each bidder shall describe how it would propose to achieve this balance.
930.6.3
Indicate the likely LSP and health community resources required, based on the implementation scenarios outlined in this OBS.
930.7
930.7.1
Bidders shall co-operate with the NASPs in meeting the criteria listed above. 930.8 930.8.1 Benefits Realisation (see also section 960.2) Bidders shall work with the Authority to identify the benefits expected to accrue from the programme. This will include end dates for delivery of the benefits and any identified financial savings.
Each bidder shall indicate its willingness to work with other service providers to deliver an integrated solution. Each bidder shall describe how it would work with NASPs to jointly deliver the requirements, and the contractual or other mechanisms it would propose to support this.
Each bidder shall provide examples of potential benefits it would expect to be realised from the implementation of LSP Services. Each bidder shall describe the processes it would put in place to ensure the delivery of benefits. Each bidder shall confirm its willingness to take on benefits realisation risk, and any constraints or conditions it would place on this.
930.8.2
Bidders shall assume responsibility for delivery of benefits attributable to the introduction of improved IT applications to support the delivery of patient care. Bidders shall accept a transfer of risk in delivering identified benefits through a negotiated contract payment structure reflecting financial incentives for delivery or non-delivery.
930.8.3
FINAL 1.0a
Page 583 of 607
ICRS
Requirement 930.9 930.9.1 Implementation Monitoring NPFIT will monitor and track the local implementations to monitor the achievement of national targets and adherence to common national standards. Bidders shall be responsible for producing regular progress reports against the implementation plans. Bidders shall establish mechanisms for managing and monitoring the ongoing implementation of new or enhanced services as the implementation process continues across the health community.
Required response
Each bidder shall describe how it will facilitate this monitoring process.
930.9.2
Each bidder shall describe how it will ensure delivery of services will be managed and monitored in a seamless fashion over time.
FINAL 1.0a
Page 584 of 607
ICRS
940 - TRAINING Requirement 940.1 Overview Effective training will be critical to the successful implementation of ICRS, eBooking and other services, and usage of any service within the health community. LSPs will be expected to work closely with the Authority and with relevant NASPs to provide training as needed. The initial outcome of this process shall be the preparation of a training plan by LSPs for discussion during the project initiation phase. 940.2 940.2.1 Identification of Training Needs Bidders shall undertake an analysis of training needs by specified user type and identify the most appropriate method of training delivery for each user group. The distinct and specific training needs of clinical, management and administrative staff shall be clearly defined and documented by LSPs as part of the training plan. The main clinical staff groups requiring access to the LSP Service shall include: consultants and other senior doctors; junior doctors; GPs; nurses (hospital and community); social workers; pharmacists, pathologists and radiologists; Allied Health Professionals (AHPs); paramedics; and NHS Direct and out of hours staff. These clinical care staff will benefit from the integration of local patient-centred information to support the operational delivery of care. They will also have an interest in the common data held on the Spine and will require training on the access routes to both local and nationally-available data. Non-clinical staff, with authorised access, are likely to require sub-sets of patient -centred clinical information across the whole local care continuum and statistical analysis for local and national purposes. These will include, but will not be limited to, managers and administrative / support staff. Each bidder shall indicate how the training needs of user would be assessed. Each bidder shall indicate what approach it has in training clinical, management and administrative staff. Each bidder shall provide its own assessment of the groups of staff who are likely to require training in order to use the LSP Services, and suggest the likely training needs for these staff groups. Each bidder shall describe its overall a pproach to the provision of training to support implementation of LSP Services, including local implementations of ICRS and eBooking. Required response
940.2.2
940.2.3
FINAL 1.0a
Page 585 of 607
ICRS
Requirement 940.3 940.3.1 The Training Plan Bidders shall produce a training plan which identifies the recommended configuration of training and associated LSP training days.
Required response
Based on the volume dataset out in this OBS, each bidder shall provide a high level training plan for the implementation of LSP Services, in line with the functional requirements and phasing outlines in Part II.1 of this OBS. As part of this, each bidder shall indicate its preference for each of the following configurations: LSP provides and delivers all training courses; cascade Train arrangements; the Trainer
LSP provides material for third party trainer to deliver; web-based training; other distance learning methods (please specify); and any other (please specify). 940.3.2 The training plan shall identify the resources required for delivery of the training (including the number of trainers; number, location and capacity of rooms; and infrastructure and equipment requirements). The training plan shall identify the split of training responsibilities between LSPs and the Authority. Training Delivery Bidders shall ensure that users will be trained to a standard that provides the skills and knowledge required to use the services fully for their role. Each bidder shall describe how it will ensure users are provided with the level of training required. Provide examples of training programmes for previous implementations. Each bidder shall describe its proposed approach to the provision of a training environment for the LSP Services. Provide indicative resource estimates for the delivery of the high level training plan, broken down by training configuration and between all the parties likely to be involved in training delivery.
940.4 940.4.1
940.4.2
Bidders shall provide a training system and database that can be used for all training purposes and refreshed as required.
FINAL 1.0a
Page 586 of 607
ICRS
Requirement 940.4.3 Information on training courses which Bidders shall supply shall include: course content; course duration and frequency; class numbers maximum and minimum; delivery method hands -on, classroom, documentation based, computer-based training, internet, or some other indicated method; and delivery agent LSPs own staff or NHS staff or third party.
Required response Each bidder shall provide information about the training programme it will propose, together with an example course prospectus.
940.4.4
Bidders shall provide all required training materials for the operation of courses. Bidders shall provide additional training material that will be available to all users as reference material. This shall be available electronically to support distance learning. It is likely that champion users will be assigned to the implementation teams. Bidders shall provide additional training to these individuals including, in relation to configuration of the new service, security structures and systems administration tasks.
Each bidder shall describe the sorts of training materials it would propose to utilise. How would the bidder expect this to be made available to staff? What additional training needs would the bidder anticipate champion users requiring? Each bidder shall describe preferred characteristics for champion users. Provide an outline of the level of training to be provided for technical staff. Each bidder shall describe its proposed approach to the assessment and evaluation of training effectiveness. Each bidder shall describe how it would achieve this.
940.4.5
940.4.6
Training shall be required for the Authoritys in-house technical staff to allow effective application support and maintenance. Bidders shall ensure that an assessment and evaluation process is in place to measure the effectiveness of training sessions and the need for further or repeat training for individual users. Bidders shall ensure that the training provided pays appropriate attention to the need for and mechanisms by which data quality, data protection and patient confidentiality is ensured.
940.4.7
940.4.8
FINAL 1.0a
Page 587 of 607
ICRS
950 - DESIGN AND DEVELOPMENT Requirement 950.1 Overview The initial design concepts for LSP Services will be evaluated as part of this procurement process. Postcontract, the selected LSPs will (where appropriate) be required to undertake detailed technical design prototypes of the local service solutions for approval by the NDA. These will incorporate the required NHS technical and data standards. 950.2 950.2.1 Initial Design Bidders shall design a solution for the operation of all elements of the LSP Services as defined in this OBS. Each bidder shall describe its overall approach to undertaking the design of the LSP Services. Each bidder shall confirm its acceptance of this requirement and outline how it intends to demonstrate its design concepts as part of the procurement. Each bidder shall describe how it would work with the NDA and local teams to develop the design and architecture for the LSP Services. Each bidder shall indicate its acceptance of this risk. Required response Each bidder shall describe its approach to design and development, particularly in relation to future requirements.
950.2.2
Pre-contract, bidders will be expected to demonstrate their design concepts as part of the evaluation process.
950.2.3
Post-contract, bidders shall work with the NDA and the Authority to prepare detailed functional and technical designs and system architecture prototypes for the proposed LSP Services.
950.2.4
The design shall be subject to approval by the NDA, whilst ensuring that the risk of design defects remains with LSPs. Bidders shall ensure that components of the technical design are compliant with existing relevant international technical standards as described in Part III of this OBS.
950.2.5
Each bidder shall confirm its understanding of these standards and how it will ensure they are met. Each bidder shall indicate its knowledge of these standards and how it will ensure they are adhered to. The bidder may suggest alterations to these standards where they do not align with the requirements of this programme.
950.2.6
Bidders shall ensure that they are familiar with the NHS published data standards, to include, but not limited to: eGovernment Interoperability Framework (e-GIF); and NHS Data Dictionary Version 2. See the URL, <http//www.nhsia.nhs.uk/datastandards> and Module 790 - Standards in Part III of this OBS.
FINAL 1.0a
Page 588 of 607
ICRS
Requirement 950.3 950.3.1 System Updates Bidders shall provide software update releases to incorporate specified enhancements as required either by NPFIT or by the Authority. The frequency of enhancement updates shall be agreed during contract discussions. Bidders shall deliver any local component of solution updates within an agreed period of time after the update has been specified. Bidders shall ensure that any solution updates have been fully tested prior to updating live end-systems environments. Bidders shall produce and implement system updates, within the prescribed timeframe, to meet the needs of any statutory changes to processes, data or system outputs as required by the Authority, including but not limited to Dataset Change Notices (DSCNs). Bidders shall ensure that full integration testing (across the LSP Services, as well as with NASP and the LSP Services provided by other LSPs) of system updates takes place prior to implementation of the update.
Required response
Each bidder shall describe its approach to the production and release of solution updates.
950.3.2
Each bidder shall indicate its proposed frequency of system updates. Each bidder shall confirm its testing process.
950.3.3
950.3.4
Each bidder shall confirm the approach it would adopt to the incorporation of statutory changes and its willingness to accept contractual risk for these changes. Each bidder shall describe how it will ensure full integration of services is maintained as a result of any updates to the LSP Services. Each bidder shall confirm its approach.
950.3.5
950.3.6
Bidders shall ensure that all Local Systems are updated to enable them to support implementation of eBooking in accordance with the required implementation plan (see section 930.1). Bidders shall implement updates to end user systems environments, taking into account any contractual arrangements in place for the support of end user systems. Future Development Bidders shall work within their Cluster in jointly producing plans for the further development of LSP Services over time. Bidders shall be able to identify a number of potential future development areas. Any design concepts for future development shall be submitted to the NDA for agreement and shall be in line with national and local priorities, guidance and standards.
950.3.7
Each bidder shall confirm its approach.
950.4 950.4.1
Each bidder shall describe its proposed approach.
950.4.2
Each bidder shall describe any view of potential future development.
FINAL 1.0a
Page 589 of 607
ICRS
Requirement 950.4.3 Bidders shall ensure that development proposals are compliant with national standards and ensure interoperability with national services.
Required response Each bidder shall describe how it would work with NASPs to ensure that future developments take place in a co-ordinated manner. Each bidder shall describe how it would ensure this is achieved.
950.4.4
Bidders shall ensure that future developments aim to protect previous investment in infrastructure and equipment. Bidders shall provide IM&T strategic advice to inform the development of updated information strategies across the health community. Bidders shall expect to be working over time with Social Services and other non-NHS organisations in developing the NPFIT vision, including ICRS.
950.4.5
Each bidder shall describe how it would achieve this.
950.4.6
Each bidder shall describe how it would extend the LSP Services to other non-NHS organisations.
FINAL 1.0a
Page 590 of 607
ICRS
960 - BUSINESS CHANGE MANAGEMENT Requirement 960.1 Overview A key element of the NPFIT is the need to link the delivery of new IT services with wider service developments and improvements in the delivery of care that NPFIT underpins. Bidders shall be required to provide a range of business change management services to enable them to work with local communities to deliver the changes in ways of working which the new IT services enable. Responsibility for business change may vary from health community to health community; but, whatever arrangements exist, bidders shall be required to work closely with local modernisation teams to bring about the required changes. 960.2 960.2.1 Business Process Change Bidders shall work with the Authority to review, and where appropriate, re-design business processes and procedures to ensure maximum benefit is gained from the implementation of the LSP Services. Bidders shall undertake a health community-wide review of existing processes as part of preparation for implementation. Processes and procedures will vary across the Trusts and healthcare sites within a health community, and a flexible approach will therefore be required. The review of current processes will seek to establish where improvements can be made in each of the following areas: quality of process; time to undertake process; steps within the process; staff resources required; cost reduction; and mitigation of current risk. Bidders shall work closely with local modernisation teams engaged in current business process reviews. Each bidder shall indicate its approach to undertaking process re-engineering exercises. Each bidder shall describe its overall approach to business change management, and how it would propose to work with local teams to deliver the required process improvements. Required response
960.2.2
Each bidder shall describe the approach it would propose to reviewing existing processes.
960.2.3
Each bidder shall describe how it would propose to achieve effective joint working. Each bidder shall describe how it would achieve this.
960.2.4
Bidders shall ensure that any proposed changes to business or clinical processes are fully consulted upon to secure staff acceptance of the usability of the solution. Bidders shall work closely with the Authority to ensure
960.2.5
Each bidder shall describe how it
FINAL 1.0a
Page 591 of 607
ICRS
Requirement that the management of cultural change is appropriately addressed together with the implementation of any redesigned processes. 960.3 960.3.1 Benefits Realisation (see also section 930.7) LSPs and the Authority shall jointly identify any benefits expected to be gained through the change management process. There is a need for a co-ordinated approach to benefits realisation which links implementation of IT services with wider process change, and this needs to be reflected in the proposed approach. Bidders shall be responsible for the delivery of any identified business change benefits arising from changes for which they have responsibility.
Required response would achieve this.
Each bidder shall describe its proposed approach to benefits identification and realisation in relation to business change.
960.3.2
Each bidder shall describe where it would expect to take responsibility for delivery of benefits resulting from business change, and where it would expect this to remain the Authoritys responsibility. Each bidder shall confirm its willingness to accept benefits realisation risk associated with business change. Each bidder shall describe how it would approach this.
960.3.3
Bidders shall accept a transfer of risk in delivering identified business change benefits through the contract payment structure reflecting financial incentives for delivery or non-delivery. Bidders shall be responsible for monitoring the delivery of benefits against plan and for regular progress reporting.
960.3.4
FINAL 1.0a
Page 592 of 607
ICRS
965 - NEW SYSTEMS AND SERVICES Requirement 965.1 Overview The introduction of a local ICRS and other services will entail a combination of: the enhancement and integration of some existing services; replacement of some existing services based on legacy systems; and the implementation of new systems and services. Each bidder shall describe its overall approach to meeting the requirements set out in this OBS, and in particular its approach to the delivery of new systems and services. The bidder should identify the specific products it are proposing to meet the requirement, including any alternatives where these exist. Required response
It is also probable that, over time, new services will be introduced within the health community that require new or innovative system solutions. Where this occurs, LSPs will be expected to implement solutions that ensure improved levels of service and the realisation of identified benefits. 965.2 965.2.1 New Systems Bidders shall provide the Authority with the preferred range of new systems and services to deliver the defined services, and shall implement new systems and services which enable the delivery of the required services in line with national and local targets and phasing requirements. This may entail the operation of existing legacy systems and the implementation of new or replacement solutions.
Each bidder shall describe its approach to identifying the programme of implementation of new systems and services, and how it will recommend preferred options.
965.2.2
Where the replacement of an existing operational system is identified, bidders shall provide the full range of implementation services required. The new systems services to be provided shall include, but not be limited to: project management; acceptance testing; data migration; user training; security and access control; operational user and technical support; system outputs; integration with local systems to form the local care record; and data exchange and integration with the Spine.
Each bidder shall indicate its agreement to this requirement and how it would approach it. Each bidder shall indicate its ability to provide these services in connection with the new systems.
965.2.3
965.2.4
Bidders shall manage and control the implementation of new systems and services and ensure that their respective consortia, if any, can collectively deliver all of the products, services and skills required.
Each bidder shall indicate how it proposes to provide seamless delivery of these products, services and skills.
FINAL 1.0a
Page 593 of 607
ICRS
Requirement 965.2.5 The risk transfer and benefits realisation requirements identified at sections 930.7 and 960.2 will apply to the implementation of new systems and services. LSPs may be required to provide a standard desktop and/or a configurable standard desktop service within a Cluster. Improved Service Levels Where new systems are implemented that replace existing systems, bidders shall demonstrate improvements in service across a range of measurable targets. These would be agreed during the negotiation process but are likely to include: improved levels of access to patient information; improved user interface and on-line help facilities; improved quality and delivery of management information; improved file and data structures to facilitate effective integration with national services including the Spine and the national eBooking service; and improved generation of returns, reports and other outputs.
Required response Each bidder shall indicate its agreement to this requirement. Each bidder shall provide details of their proposed desktop solutions.
965.2.6
965.3 965.3.1
Each bidder shall describe how its proposals will seek to deliver these improved service levels.
FINAL 1.0a
Page 594 of 607
ICRS
970 - OPERATIONAL SUPPORT Requirement 970.1 Overview Once the final scope and nature of the LSP Services have been agreed, bidders shall commence the delivery of a range of specified operational services. The type and nature of operational services required may vary between Clusters. It could require a fullymanaged service provided either on or off site. Alternatively, LSPs may work in conjunction with local IT services and health informatics teams within the health community to deliver the services. Part III of this OBS outlines the service levels and standards defining, amongst other issues, service availability, performance and response times. 970.2 970.2.1 Service Functions The specific operational responsibilities of an LSP shall be agreed in advance with each Authority. The range of services identified below represent a guide to what bidders shall expect to provide. Bidders shall provide the operational and technical functions of legacy systems and new systems as they are implemented. This will include the execution of all batch processes and programs required to maintain the service. Bidders shall provide technical and application support to deliver integrated LSP Services. This will include, but not be limited to: back-up and housekeeping routines; performance monitoring and tuning of applications; user advice and queries; database administration; and implementation of system upgrades. Each bidder shall describe how it would propose to adopt these responsibilities for legacy systems. Required response Each bidder shall describe its overall approach to the delivery of an operational service for local ICRS, eBooking and other services.
970.2.2
970.2.3
Each bidder shall describe its approach to the provision of a technical and application support service. The bidder must indicate the full range of services it would expect to provide.
Also see the description of the Help Desk Service in Part III of this OBS. 970.2.4 Bidders shall provide training for local staff involved in the delivery of the operational service (where relevant). The requirement for training will be dependent on the division of responsibilities between LSPs and the Authority. Each bidder approach to training in operational provides. shall indicate its the delivery of relation to the service that it
FINAL 1.0a
Page 595 of 607
ICRS
Requirement 970.2.5 Bidders shall provide a reference data maintenance service that shall include, but not be limited to: maintenance of central tables in each application for national and local codes, including consultant, GP, clinical diagnostic and procedure codes, postcodes; and updating and synchronisation of reference data across applications, including those provided by NASPs.
Required response Each bidder shall describe its proposed approach, and in particular how It would propose to work with NASPs, other LSPs and the NDA to deliver an integrated service.
970.2.6
Bidders shall provide a helpdesk facility that will be the prime point of user contact for ICRS users within the health community. This service is further defined in Part III of the OBS. Bidders shall ensure that business continuity is assured (see Part III of this OBS).
Each bidder shall indicate its acceptance of this requirement and refer to its detailed response in Part III of the OBS. Each bidder shall describe its proposals for ensuring business continuity. Each bidder shall indicate its approach to prioritising systems and matching to the appropriate level of resilience.
970.2.7
970.2.8
Bidders shall ensure that appropriate resilience is established for each application. Bidders shall match the criticality of applications with appropriate disaster recovery plans. Resilience levels may include, but not be limited to: mirrored disks and duplicate on-site processors; duplicate off-site processors; resilient networking arrangements; and back-up and off-site storage of data. Bidders shall manage the data and file structures of applications utilised to deliver LSP Services to the required standards for integration with the Spine and other National Applications. Bidders shall provide a common user interface for the LSP Services, meeting a range of basic requirements, including the following: presentation of information in an easily-readable format; users shall be able to retrieve their most commonlyaccessed features and data; and sparing use of graphics to reduce browser response times. Bidders shall amend the user interface to meet local requirements for innovation.
970.2.9
Indicate its approach to this requirement.
970.2.10
Each bidder shall describe its proposed approach to the delivery of a common user interface for the LSP Services.
Detailed performance standards are defined in Part III of the OBS.
FINAL 1.0a
Page 596 of 607
ICRS
Requirement 970.3 970.3.1 Performance Standards Bidders shall adhere to the required range of data and system standards in the delivery of LSP Services. Part III of this OBS defines the appropriate standards.
Required response
Each bidder shall indicate its acceptance of this requirement and refer to its detailed response in part III of the OBS. Each bidder must provide examples of the sorts of performance reports It would expect to produce.
970.3.2
Bidders shall provide monthly, quarterly and annual reports on performance against the required standards.
FINAL 1.0a
Page 597 of 607
ICRS
975 - INTEGRATION AND DATA OUTPUT SERVICES
Requirement 975.1 Overview Integration will be crucial to the success of the implementation of ICRS, eBooking and other national services and LSP Services. The integration requirements will vary across care settings within a health community and within the mix of legacy and new applications. The aim will be to create a local end user environment that provides the appearance of a seamless system structure. It will also be essential that the LSP Services follow the definitions and standards specified by NPFIT to ensure upward integration with the national services and other LSP Services, including the Spine. 975.2 975.2.1 Local Integration Bidders shall work closely with the Authority to identify the local integration requirements and options for achieving a seamless systems environment. Integration shall be achieved without measurable disruption or degradation to the end-systems environment. Integration could be achieved through various approaches, which could include interfacing and/or messaging. A range of local integration categories will apply. These shall include, but not be limited to: new applications to retained legacy systems; new applications to local systems; e.g., pathology; and integration across care settings; e.g., the combination of acute and Primary Care data.
Required response Each bidder shall outline its overall approach to ensuring integration of data across separate systems and services.
Each bidder shall outline its initial proposals for achieving local integration in order to achieve a seamless end user environment.
975.2.2
Bidders shall work together to ensure data integration between Clusters can be achieved.
Indicate proposals for ensuring the interoperability of systems between Clusters and joint working between LSPs.
FINAL 1.0a
Page 598 of 607
ICRS
Requirement 975.3 975.3.1 National Integration The NASPs and the NDA will define the common data requirements to be extracted from Local Systems. Bidders shall ensure these data are available for extraction within source systems. Bidders shall ensure that: data structures within local solutions are consistent with national requirements and standards; data output files are produced from both new and legacy local systems in a standard format; and electronic data exchange mechanisms are established. Seamless electronic data exchange routines shall be established by LSPs between local feeder systems and the Spine that are easy to use and will support the transfer of all file types within a secure infrastructure. Bidders shall ensure that common data items are flagged within the local operational systems for data transfer to the Spine.
Required response
Each bidder shall describe how it would address this.
975.3.2
This process will require joint working between the NSP and LSPs. Each bidder shall describe the mechanisms it would propose to bring about this coordinated approach.
975.3.3
Each bidder shall outline its proposals for establishing a secure data exchange mechanism. Each bidder shall provide an overview of how healthcare events might trigger information to be communicated with the Spine. Each bidder shall confirm the messaging standards that will be supported.
975.3.4
975.3.5
Data transfer/messaging shall support the following file types: XML; HMTL; comma delimited; zip files; Excel; and others as required by the Authority. The transfer of patient data shall be encrypted and held within a sec ure environment. This requirement is described further in Part III. Data exchange shall support both one-way (unidirectional interface) and two-way (bi-directional interface) transfer. Audit Trails shall be maintained for data transfer to include the following parameters: date/time of file upload; user organisation ID; unique file name; file size;
975.3.6
Each bidder shall describe how this might best be achieved.
975.3.7
975.3.8
Each bidder shall describe its approach to the production of Audit Trails and how these would be used to assure the integrity of data held within the Spine.
FINAL 1.0a
Page 599 of 607
ICRS
Requirement 975.3.9 file type; and sender ID.
Required response
Bidders shall provide data extract routines to allow interchanging of data with the Spine to be appropriately tested and validated. Other Local Outputs Bidders shall ensure that local systems have the capability to support local control over reporting, analysis and presentation of information derived from the composite ICRS to support secondary information requirements including, but not limited to clinical audit, research, service management and planning and health needs assessment. Other National Outputs Bidders shall ensure that local systems produce other outputs of data in the form required by other national services, including (but not limited to) the NHS-Wide Clearing Service (NWCS), the Hospital Episode Statistics service (HES), the National Patient Record Analysis Service (NPRAS) and the National Clinical Audit Support Service (NCAS). NWCS (NHS Wide Clearing Service) As specified in 975.5.1, bidders shall ensure that local systems produce outputs of data in the form required by other national services, including (but not limited to) the NHS -Wide Clearing Service (NWCS). The requirements for the format of data records required by the NHS-Wide Clearing Service are controlled by NHSIA Data Standards, and are defined within Data Set Change Notices (DSCN) issued from time to time as authorised changes occur. The last data year for which data will be processed by the current NWCS is 2004-05. The replacement for NWCS shall receive data for the 2005-06 data year, but shall also support previous data years, including receipt of latest data for 2004-05 which may continue through to June 2005 The service shall accommodate all new data flows which have been agreed through the ROCR / ISB process.
975.4 975.4.1
Each bidder shall confirm that It will comply with this requirement.
975.5 975.5.1
975.6
FINAL 1.0a
Page 600 of 607
ICRS
Requirement 975.6.1 Transition and Continuity of Service The timing of the transition in relation to the annual cycles of NDS data flows will have a major impact on the transition process and on the data flows to be supported in the early months of the new service. These data flows will clearly be those most at risk from development delays or problems with the new service. The most important of these are the commissioning flows to PCTs and the HES extracts. Trusts complete their submissions for the HES calendar year extract in February and the extract is produced around February/March each year. Submissions for the end of the financial year (to March) are important for commissioners and arrive in May from healthcare providers. The transition process shall be designed to ensure the continuity of these flows. 975.6.2 Common identification of senders and recipients records between
Required response Each bidder shall confirm that It will comply with this requirement.
A Record Identifier (RID) field will be included in all NDS to enable the unique identification of every NDS record. This is different from the current UID which is an event identifier used by the Net Change protocol, and is not necessarily unique to every record. The RID is a fully defined identifier that does not contain any patient identifiers, and might for example be constructed as: <Provider Code><Date/Time of Batch><Record Number in Batch>. It is intended to propose the inclusion of the RID as a change to the NDS standard. 975.6.3 Submission and Receipt of records The service shall support the preparation and submission of NDS records in eGIF compliant format and the processing of eGIF compliant formatted NDS records forwarded to Commissioners. The current service features bulk update and netchange update protocols. These will need to be supported at least during transition from the old service. The NDS Transfer Service shall inter-work at all times with the NDS Processing Service and Secure Database Service so that changes to the NDS standards affecting these services are co-ordinated with changes to local conversion/translation functions within the scope of the NDS Transfer Service. All data sent shall be encrypted and all messages received shall have been encrypted and will therefore Each bidder shall confirm that It will comply with this requirement.
FINAL 1.0a
Page 601 of 607
ICRS
Requirement require decryption. Pseudonymisation of data will be performed in the central service. LSP services do not need to perform pseudonymisation. 975.6.4 Data Quality Mechanisms Submissions shall be validated for data quality, addressing and format to ensure that there are no rejections by any part of the subsequent processing onto the central database and transmission to recipients. The service shall be capable of incorporating additional data quality checks as currently defined and modified from time to time. The central validation will report any suspected data quality problems in a standard file format. This may include suggested corrections. The service shall be capable of using this file to perform semi, or fully, automatic data correction The service shall be capable of retransmitting data that has been modified. 975.6.5 Addressing service In the existing service healthcare providers use the CDS addressing Grid to determine the prime and copy recipients for each NDS record. A facility shall be provided as part of the NDS Processing Service to allow use of the addressing grid at the healthcare provider site to automatically complete the NDS address fields based on data available in the NDS record. It shall be possible to include other recipients in addition to those required by the addressing grid and populated automatically by this service.
Required response
FINAL 1.0a
Page 602 of 607
ICRS
980 - LEGACY MANAGEMENT Requirement 980.1 Overview LSPs will in some cases be expected to provide a continuation of IT services from existing legacy systems within the health community. Legacy system service levels will be agreed between LSPs and the Authority. Where legacy systems are replaced by new system implementations, LSPs will be expected to prepare and agree detailed migration plans with the Authority. 980.2 980.2.1 Continuation of Legacy Systems LSPs and the Authority shall agree and document the specific system and module details that will be subject to the legacy management services. Legacy systems for which the LSP assumes responsibility must be provided at level of service and functionality not less than that provided prior to the commencement of legacy services. LSPs and the Authority shall define the service levels to apply to the legacy management s ervices. These shall include system availability times and system response times. Bidders shall agree to performance targets against the service levels and will provide regular monitoring reports of actual performance against target. Contract Management and Novation Where existing legacy systems are to continue and are subject to contracts with third party LSPs, these contracts shall be either: novated to LSPs; or managed by LSPs on behalf of the Authority; or continue to be managed by the Authority Where a contract is novated, deeds of novation shall be agreed between LSPs, health community and relevant third party on the basis of a standard form provided by the Authority, where possible. Each bidder shall indicate its preparedness to accept either of these options, and any preferences it has in relation to legacy contracts. Identify any existing implementations that involve the continuation of legacy systems. Each bidder shall describe how it would ensure service levels are maintained and ideally improved. Required response Each bidder shall describe its overall approach/philosophy towards the management of legacy systems, and the role it sees legacy systems playing in the delivery of LSP Services.
980.2.2
980.2.3
Each bidder shall address this requirement in its response to Part III of this OBS.
980.2.4
Each bidder shall address this requirement in its response to Part III of this OBS.
980.3 980.3.1
980.3.2
Each bidder shall confirm its agreement to this requirement.
FINAL 1.0a
Page 603 of 607
ICRS
Requirement 980.4 Migration from Legacy Systems (see also Module 930 Implementation) Bidders shall, where they are providing a replacement to legacy systems, prepare detailed migration plans for approval by the Authority.
Required response
980.4.1
Each bidder shall outline its approach to managing data migrations as part of new systems implementations. Each bidder shall confirm its approach.
980.4.2
Bidders shall ensure that any migration will be capable of being phased in terms of functionality (e.g., by module) and groups of users. All appropriate historical data held in the legacy service shall be agreed with the Authority and converted to the new system. Bidders shall define and agree with the Authority the level of data quality required prior to conversion and the responsibility of each party with regard to data preparation. Bidders shall ensure that no data is lost, corrupted or duplicated during the migration process. Bidders shall plan and demonstrate that there is an appropriate, secure regression path shall any aspect of the data migration fail.
980.4.3
980.4.4
980.4.5
Each bidder shall confirm its approach. Each bidder shall confirm its approach.
980.4.6
FINAL 1.0a
Page 604 of 607
ICRS
985 - INFRASTRUCTURE SERVICES Requirement 985.1 Overview It is probable that LSPs will, in certain Clusters, be required to adopt responsibility for the IT infrastructure required for the delivery of effective local IT services. This may involve assuming responsibility for managing all aspects of the technical services relating to delivery of the systems to end users, and could include taking over the existing infrastructure or installation of new or upgraded infrastructure. The range of infrastructure services required will vary between Clusters. The range of services identified below represents a guide to what LSPs could expect to provide. Alternatively, LSPs may be required to define the infrastructure environment required by the Trusts and healthcare sites within the health community to provide a warranted level of service performance. LSPs will be responsible for cabling within a Cluster as determined by the Authority. 985.2 985.2.1 Local Infrastructure Management Where an LSP is required to operate an end-to-end service they shall manage and maintain the local infrastructure. Where responsibility for providing an end-to-end service exists, bidders shall adopt responsibility for providing and maintaining workstations and establishing a standard desktop front-end for all applications and services. In this situation, bidders shall expect to be responsible for the provision and maintenance of peripherals, including printers, scanners and barcode readers, as part of an end-to end service. Bidders shall be responsible for the provision and management of a modern and integrated network infrastructure. This will include: existing legacy local area network provision; Wide Area Network connections to national infrastructure services (NHS N3); development of connections to and from the Spine; and monitoring and reporting end-to-end service performance. Each bidder shall provide an overview of its approach to managing local infrastructure. Each bidder shall describe its proposed approach to the provision of an end to end IT service, including the provision and maintenance of end user devices. Required response Each bidder shall describe its overall approach to the provision of services associated with the management of local infrastructure.
985.2.2
985.2.3
Each bidder shall describe its proposed approach to the delivery of network services, including how it would work with NISPs to deliver a seamless IT service to us ers. Bidders should provide details of their approach to managing network services.
FINAL 1.0a
Page 605 of 607
ICRS
Requirement In delivering local infrastructure services, Bidders shall ensure they are aware of the appropriate NISP initiatives and work with them to ensure local conformance. Initiatives include: Wide Area Network and broadband capacity NHS N3; delivery of modern email services; and implementation of the national NHS Directory Service. Where network services are provided, bidders shall ensure they are capable of integration with the national infrastructure initiative for the provision of Wide Area Network and broadband capacity NHS N3. It is imperative that LSPs and the N3 NSP work together to provide integrated services which will enable clinicians to work efficiently and effectively across cluster boundaries in support of the needs of patients, including access to local ICRS facilities, such as Video Conferencing and full ICRS records across such boundaries. Where LSPs become responsible for ensuring connectivity, they shall expect performance measures, in the form of response times, to be set by the Authority. Bidders shall provide a technical helpdesk facility for the logging of faults and an end user team of technicians to resolve reported faults and user problems. Bidders shall establish cost structures that provide the health community with unitary charging tariffs. This would provide standard pricing for a given item; e.g., an approved desktop or laptop computer. Bidders shall be expected to establish cost structures that provide the health community with scenario pricing structures. This would provide standard pricing for a given service; e.g., repair of a given device at any location within the health community.
Required response
985.2.4
Each bidder shall indicate its awareness of the national infrastructure initiatives, and how it would work with NISPs to deliver a seamless IT service to users.
985.2.5
Each bidder shall indicate its agreement to this requirement.
985.2.6
Each bidder shall address this requirement in its response to Part III of this OBS. Each bidder shall describe its proposed approach to delivering end user support services. Each bidder shall describe its approach.
985.2.7
985.2.8
985.2.9
Each bidder shall describe its approach.
FINAL 1.0a
Page 606 of 607
ICRS
Requirement 985.3 985.3. 1 Warranted Environment Where an LSP is not required to manage the local hardware and network infrastructure, then the LSP shall issue the Authority with an environment specification. This will define the infrastructure required for each Trust or healthcare site within the health community, to ensure that performance targets set in the service level agreements are met. The service levels (for system performance) will then be warranted by LSPs for users on the health community infrastructure. The environment specification will cover as a minimum: workstations and servers; client PCs; printing; other peripheral devices (scanners, bar-code readers, etc.); and network bandwidths and protocols required to meet the required performance targets.
Required response
Each bidder shall outline its requirements for reviewing the health community infrastructure.
FINAL 1.0a
Page 607 of 607

OBS

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

OBS

Încărcat de

Drepturi de autor:

Formate disponibile

ICRS

Output Based Specification

Integrated Care Records Service

Output Based Specification Second Iteration

Output Based Specification

Output Based Specification

Output Based Specification

Visioning the LSP Services

Output Based Specification

Output Based Specification

Scope of LSP Responsibility

INTEGRATED CARE RECORD SERVICE

NHS Spine Personal Demographic Services

Confidentiality Authentication Order Entry E-prescribing Results Reporting Graphical Analysis

Ambulatory Care Management

Flexible Toolkit to Support Range of Data and Viewing Requirements

Electronic Transfer of prescriptions

Child Health Screening Respite Care Trauma Rehabilitation

Theatres Intensive Care

Old Age Psychiatry Endoscopy

Range of Care Settings

Output Based Specification

Output Based Specification

Enhanced role paramedics

Nurse led services

Output Based Specification

Integrated emergency teams

Hospital outreach teams integrated community care

Output Based Specification

Extended support and nursing roles in primary care

On-the-spot booking system

E-prescribing primary care

Output Based Specification

Digital transfer images PACs

Integrated care with effective communication

Output Based Specification

Output Based Specification

Bridging the Gap

Output Based Specification

Where possible, lessons learnt should be used.

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Output Based Specification

Required Response deliver during Phase 1.

Each bidder shall describe how this will be achieved.

Each bidder shall describe how this will be achieved.

Each many would order,

Each bidder shall describe how this will be achieved.

Each bidder shall describe how this will be achieved.

Output Based Specification

Required Response actions performed for the data entry itself.

Each bidder shall describe how this will be achieved.

Output Based Specification

Output Based Specification

Output Based Specification

Each bidder shall describe how this will be achieved.

Each bidder shall describe how this will be achieved.