Stage 3 Build, Configuration & Testing Stage 4 Operational ......UAT User Acceptance Testing X-Lab Name of service provider 2. Background This guide is designed to support labs staff

National Laboratories Programme

NPEx Implementation Pack 2

Stage 3 Build, Configuration & Testing

Stage 4 Operational Deployment

Version: 1.0

Contact: [email protected]

mailto:[email protected]

NPEx Implementation Build and Configuration Guide v1.0

Page 2 of 22

Document Control

Authors:

Name Title Role

Matt Noel Labs IT Manager – NHS Lothian Subject Matter Expert

Charlotte Syme Clinical Scientist – NHS Greater Glasgow & Clyde Deputy Clinical Lead

Revision History:

Version

Number

Revision

Date

Previous

Revision

Date

Summary of Changes Changes

Marked

V0.1 05/11/18 N/A Document Creation N/A

V0.2 10/12/18 05/11/18 General review, edits on structure and content Yes

V0.3 18/01/19 10/12/18 Comments on edits from previous version Yes

V0.4 31/01/19 18/01/19 Final review of content Yes

V0.5 14/02/19 31/01/19 Review of document purpose and content Yes

V0.6 25/02/19 14/02/19 Updated as per review between SG, KW, MN &

CS

No

V0.7 05/03/19 25/02/19 Updated visual diagrams and edits on format No

V0.8 18/03/19 05/03/19 Changes made as per feedback No

V0.9 01/04/19 18/03/19 Changes made following feedback from MT No

V0.10 02/04/19 01/04/19 Changes to format and flow following review by

CS

No

V0.11 04/04/2019 01/04/2019 Changes made as per CS/ SG review No

V0.12 12/04/2019 04/04/2019 Updates made to Appendices No

Approvals:

Name Title Date Version

Kim Walker National Laboratories Programme Manager

Distribution:

Name Title Date Version

Kim Walker National Laboratories Programme Manager

Suzanne Tate National Laboratories Programme Project Manager

Sarah Gibson National Laboratories Programme Project Manager

Shirley Higgins National Laboratories Programme Project Manager

Jennifer Downie National Laboratories Programme Project Support

Officer


Page 3 of 22

Contents

Document Control ...................................................................................................................................... 2

1. Glossary ............................................................................................................................................. 4

2. Background ........................................................................................................................................ 4

3. Practical Laboratory Considerations ................................................................................................... 4

4. Tasks, Roles and Resource Requirements for Build Configuration & Testing and Operational

Deployment ............................................................................................................................................... 5

5. Stage 3- Build, Configuration & Testing .............................................................................................. 5

5.1 LIMS Interface Configuration ....................................................................................................... 5

i. Interface Build – LIMS Elements ..................................................................................................... 5

ii. Interface Build – NPEx Configuration .............................................................................................. 7

iii. Interface Build – LIMS Setup ........................................................................................................... 8

5.2 TEST / DEMO Environment Configuration ................................................................................... 8

5.3 Build and Configuration- Live Environment ................................................................................ 11

6. Stage 4 Operational Deployment ...................................................................................................... 14

6.1 Operational Go-Live ....................................................................................................................... 14

7. Contingency...................................................................................................................................... 16

8. Documentation ................................................................................................................................. 16

9. References ....................................................................................................................................... 16

Appendix 1 – Setup ................................................................................................................................. 17

User Experience – Lothian requests to Glasgow Royal Infirmary (GRI) Biochemistry .............................. 17

Appendix 2 – Workflow ............................................................................................................................ 19

Appendix 3 – Testing Plan ....................................................................................................................... 20

Appendix 4 – Issues ................................................................................................................................ 21

Appendix 5............................................................................................................................................... 22

Test Catalogue: Work sent from Lothian to GRI Biochemistry.................................................................. 22


Page 4 of 22

1. Glossary

The following terms appear throughout this document and its related attachments:

Abbreviation Definition

BAU Business as Usual

BMS Biomedical Scientist

IT Information Technology

LIMS Laboratory Information Management System

LOB Laboratory Oversight Board

NLIIP National Laboratories Information and Intelligence Platform

NLPT National Laboratories Programme Team

NPEx National Pathology Exchange

SME Subject Matter Expert

SOP Standard Operating Procedure

THIS The Health Informatics Service

UAT User Acceptance Testing

X-Lab Name of service provider

2. Background

This guide is designed to support labs staff within NHS Boards tasked with the build and configuration of

NPEx and will provide guidance and support throughout Stage 3 (Build, Configuration & Testing) and

Stage 4 (Operational Deployment) of NPEx, as shown in the deployment approach diagram in Section 3.

This document provides an overview of the steps required, learning and useful information based on

experiences from NHSScotland Health Boards who have deployed NPEx to date and is designed to walk

readers through stages three and four of the below approach to provide an overview of steps required to

be taken throughout, alongside providing an overview of expertise and estimated time requirements to

support successful implementation.

Further to this an example of deployment between Glasgow (GGC) and Lothian Biochemistry laboratories,

that may help illustrate the process, has been included in the appendices.

3. Practical Laboratory Considerations

The introduction of NPEx should aim to work alongside any current send away test systems already in

place but it should be noted that existing send away test systems will remain for a number of tests and will

provide contingency for any NPEx downtime.


Page 5 of 22

4. Tasks, Roles and Resource Requirements for Build Configuration &

Testing and Operational Deployment

The table below outlines the key roles in stages three and four of deployment. How an individual

laboratory decides which staff members will be doing the configuration and testing is up to them but it is

worth considering the skills required and whether the new skills learned will be retained in the lab. This is

the core part of the build that is best served by some understanding of technical, clinical and operational

requirements surrounding send-away tests as well as some basic IT skills.

Task Suggested staff Roles / Abilities Time Required

LIMS Configuration

BMS / Clinical Scientist with LIMS knowledge / skills

Ability to create new tests and amend existing tests to work with NPEx.

Likely some time every week in the Pipe Cleaning, UAT and LIVE stages of the plan.

NPEx Configuration

BMS / Clinical Scientist with LIMS knowledge/skills

Ability to create new tests and amend existing tests to work with NPEx.

Likely some time every week in the Pipe Cleaning, UAT and LIVE stages of the plan.

Testing - Pipe Clean

Ideally BMS / Clinical Scientist with LIMS skills

Needs to be able to request and result tests and document outcome.

Less than 1 day.

Testing - UAT Ideally BMS / Clinical Scientist with LIMS skills


Likely a few days over 1-2 weeks.

Testing - LIVE Ideally BMS / Clinical Scientist with LIMS skills


Likely a few hours/days every week for 4-6 weeks.

Operational Go-Live

Reception Manager

Understands current work process and the new NPEx process. Ability to train lab staff in new processes.

1-2 days at go-live.

5. Stage 3- Build, Configuration & Testing

This stage is where tests to be exchanged are configured in both the LIMS and NPEx by the nominated

members(s) of staff (laboratory BMS/Clinical Scientist). It is recommended that the below guidance for

stages three & four are read through completely beforehand to allow for foresight of issues that may arise

and configuration changes to implement from the very start. There is an element of repetition at this point

as tests are configured and verified to demonstrate the core elements of the interface works with the

NPEx dummy hospital (pipe cleaning). Then an expanded set of tests in your Test/Demo LIMS through

test NPEx with an NHS testing partner which is an opportunity to explore the configuration limits and

capabilities as well as a pre-amble to the live configuration. Finally, the process is repeated by testing in

the live LIMS/live NPEx to verify the set-up before going operationally live.

5.1 LIMS Interface Configuration

i. Interface Build – LIMS Elements

Your LIMS supplier in communication with X-Labs will handle the fundamentals of setting up a LIMS

interface and likely they will supply an existing interface they have built already. However the following

points will help consolidate your understanding of the interface and ensure your LIMS supplier is

accommodating key functional requirements. As such these points should ideally be considered before

the build and configuration of the interfaces begins.


Page 6 of 22

How does the interface stay “up”? Is there a send/receive message at regular intervals to keep the

interface from dropping connection? Both the LIMS supplier and NPEx should be asked to ensure

that the interface doesn’t drop connection if there is no activity.

Determine how messages are handled in the event of an NPEx or LIMS outage & recovered

thereafter (contingency).

Interface legs – the LIMS supplier may specify send/receive channels accordingly for the 4

elements of the interface; ‘outbound’ requests out, results in, ‘incoming’ requests in, and results

out.

Understand what prompts the interface to create an order and how profile (set) codes vs. test

codes prompt the interface. Tests will file to the interface as designated by the interface

configuration and create an NPEx order as set-up in the NPEx configuration. For example in

Lothian test codes are configured to file to the interface by a LIMS routine and profile (set) codes

containing those test codes will also file.

Inbound Order Comms messages may have a unique LIMS order number added to them, the

structure of which you may wish to specify to the LIMS supplier. For example, Lothian order

numbers are generated by the LIMS but we asked to prefix with NPL to distinguish from TRAK or

GP Order Comms.

Clinical details. For both incoming and outgoing messages – ideally need to be able to accept as

many characters as possible but aim to get the relevant clinical details output to your request.

Point to note the capacity to send and receive clinical details through NPEx may be limited by field

size in the LIMS of sending/receiving labs.

Demographics (1). NPEx passes demographic data unaltered and each LIMS interface may have

variations of how demographic exceptions are handled. LIMS supplier should be queried as to how

the demographics are processed and whether there are rejection criteria for non-alphanumeric

characters, field size, etc. This is a high level decision to be made at the outset. It is

recommended that interface Patient Matching Algorithm allows all orders to be accepted unless

interface level rejection messages are appropriately monitored. Be aware of any downstream

consequences (i.e. record merge or duplicate records) this creates. For example, GGC initially did

not allow new records to be created and an exception was made. However there was no obvious

error message and the only way to identify the issue was to look into the interface error log. GGC

decided to allow all new records and now has to manage the duplicate record consequences.

Demographics (2). NPEx can file hospital number, CHI number and NHS number. The LIMS

provider should be able to provide details on the matching rules for your interface. It is then

important to determine how to handle unexpected characters or formats as each board may map

CHI/NHS/Hospital number differently. Need to understand how this will affect booking in of

samples and if new records will be created.

Demographics (3). CHI should be the main patient identifier in Scotland; however each Board

LIMS may have this in a different field in their LIMS. It is important to understand your LIMS

demographics setup as this will affect the information received by a receiving lab. For example

GGC have a number of duplicate records as a Hospital number is bring received instead of a CHI

number. Ensure requests file out the CHI number to NPEx as the main patient identifier.

Requesting lab to identify result/test field limitations and how exceptions to those limits are

handled. For example in Lothian APEX test result field takes a maximum of 6 digits so results

exceeding this are filed by the interface as a test comment prefixed with “Result =”.

Understand how test result comment codes are handled, a coded comment for a result field will

have the comment expansion filed from the performing lab, not the code.

Reference ranges. Some LIMS systems do not handle reference ranges of <n (such as APEX).

APEX prefers a 0 – n approach. Results may not ‘flag’ appropriately in downstream systems such


Page 7 of 22

as SCI store / TrakCare. This can be managed in the interface build by forcing a ‘0 – n’

amendment.

Interface messaging can be affected by characters mistaken as message queues. For example the

GGC interface was reading ‘ORC’ from address ORCHARD as a HL7 segment header and could

not then file the record into the LIMS. The LIMS provider was able to put a fix in place to overcome

this.

NPEx provides the external lab reference number for inbound requests. Although non-essential, it

is useful to ensure the interface files this to the request in your LIMS (if there is a field available).

This improves data quality and verification, and also allows for contingency processes.

The validation level of inbound results (how results are authorised) should be agreed and

specified. For example Lothian has all inbound results from NPEx set in the interface to file at

“technically validated”. GGC captures all results in an authorisation queue.

ii. Interface Build – NPEx Configuration

General:

NPEx have recently developed a mechanism for sending request information (such as urine

volume), however this has not yet been introduced in Scotland. Other options for request

information include ‘Manifest details’, or ‘Specimen Details’ but these are not mapped fields.

Manifest and/or Specimen details can be printed on the shipping manifest to assist the receiving

lab. These must be ‘ticked’ in Manifest setup.

Specimen types. NPEx requires that the specimen type in the sending and receiving lab match. It

is likely that many health boards have different approaches to specimen type. Ensure all probable

specimen types are included in the test catalogue, including those generated by electronic ordering

system (such as TrakCare).

Any possible Reflex tests MUST be mapped between sending and receiving LIMS. If they are not

mapped, the message will fail.

Analytical/Receiving lab:

Any tests added on by the analytical lab MUST be mapped in NPEx (and to receiving LIMS) or

results will not transmit (results will fail subsequent to the test that is not mapped). For example, if

Glasgow adds a CRP as part of a Nutrition screen and this result is NOT mapped back to NPEx

and sending LIMS, the message will fail and a Notification message will be generated in NPEx.

The shipping manifest is configurable to work with whatever the lab setup requires and can be

specific for any single lab. For example Glasgow Royal Infirmary (GRI) Biochemistry has specified

only one sample per manifest as this is required for the complex reception sample handling. NPEx

has an extensive catalogue of tests available to choose from when building the local catalogue. If

there is not a suitable test name available, a new one can be created. During the NPEx

implementation, this can be submitted to your NPEx Project Manager, then later when in BAU, a

request can be made to the NPEx Remedy on Demand (RoD) change request (any user can

request access to this). For example Glasgow has taken the approach of assuming ‘serum’ for all,

and for any other specimen types, the test name includes the specimen. For example ‘androgen

screen’ for the serum androgen screen, as opposed to ‘blood lead.


Page 8 of 22

iii. Interface Build – LIMS Setup

All ‘non-Optional’ tests MUST be mapped to NPEx or the rest of the results will not transmit. For

example in DXC Telepath there is the ability to have ‘Optional tests’ within a Set. However if these

are results that may sometimes be transmitted, they should be mapped in NPEx.

All ‘non-Optional’ tests MUST contain a numerical value or characters such as ‘NA’, otherwise

receiving LIMS will be incomplete.

For analysing lab with DXC Telepath LIMS, Location codes MUST be set to HISS reportable for

results to transmit (may be an equivalent setup for other LIMS databases).

An interface test cross-reference in the LIMS for building sets (profiles) or tests that are exchanged

with the interface will need to be configured for each test and possibly across multiple relevant

interface legs. For example the outgoing request interface may need the set (profile) codes built

and the inbound results interface will need the test codes built, based on a DXC APEX experience.

Referral labs must be able to receive all results sent back to them in the interface message,

otherwise the message will fail. This may require build in the referral lab LIMS of extra tests, which

the lab may choose to be non-reportable. For example CRP in a Nutrition screen from GRI

Biochemistry has been mapped to a non-reportable ‘GGC CRP’ test in the Tayside LIMS.

5.2 TEST / DEMO Environment Configuration

At this stage exchanging labs will configure the agreed list of tests in their Test/Demo LIMS environment

and the Test NPEx environment. This is an opportunity to determine what makes sense to test as an initial

tranche when you move to the live system but importantly should also be used to explore the functionality

and boundaries of the system. The NPEx_Example_UAT document outlines the key test exchanges and

users should satisfy themselves to their own requirements for what they expect from NPEx. To that end

testing partners may wish to demonstrate exchanges that don’t normally occur (e.g. being the sender if

one lab is always usually performing) to enhance understanding and possibly preparation for if that

scenario arises.


Page 9 of 22

[2] Contact Testing LabAgree initial tests

Interface Test Verification Workflow TEST/DEMO Environment

[3] Performing LabConfigure and map Tests in

NPEx

[4] Performing LabConfigure Tests in LIMS

[5] Sending LabMap Tests in NPEx

[6] Sending LabConfigure Tests in LIMS

[7] Testing Test Parameters Demographics Test Value boundary testing Unexpected values Unit of Measurement Reference Ranges Comments Clinical DetailsAll filings correct þ

[8] Complete Pipe clean/UAT Document

[9] Interface test approval

TEST/DEMO

Environment

[1] Ensure site to site configuration set up in NPEx

6. Site to site configuration and My Lab setup. In ‘Site to Site Config’, ensure the Local Board LIMS

is configured in NPEx along with the partner site LIMS and department level disciplines. In ‘My lab’

setup, ensure the Lab name identifies both the Hospital AND the Town/City, for example Glasgow

Royal Infirmary. Also a general phone number and email address for NPEx related enquiries. In

addition, the ‘Result Behaviour’ setting can be configured to the local requirements, such as adding

the analytical lab name to all results.

7. Agree UAT tests. A number of tests should be chosen and agreed between the lab, testing partner

and Regional Project Manager to verify both the interface performance and the configuration of tests


Page 10 of 22

for exchange in NPEx and the LIMS. Tests should ideally be cross disciplines (if relevant) and

different test types (numeric, alphanumeric, textual etc). These tests will be configured in the LIMS to

exchange results with NPEx as well as configuration within NPEx itself. In terms of workload this

should be quick and easy to do with sufficient coordination with the partner lab. The verification

process itself requires a substantial amount of work as coordinating and documenting the various

testing criteria can be time consuming and requires a high degree of attention to detail.

NOTE: ALL tests resulted by the performing lab MUST have a corresponding result field in the

sending lab. For example if a urine creatinine is required to interpret a result, this result will be

transmitted to NPEx and will need to be mapped back to the sending lab (this could be as a non-

reportable result).

8. Performing lab – configure and map tests in NPEx. The NPEx catalogue has a comprehensive

list of tests already available. However if a new test is required, this can be built by X-Labs. SNOMED

codes can be used to assist with the test selection. Once mapped, the NPEx test details and

SNOMED code (if available) should be added to the Excel ‘test mapping template’ spreadsheet.

9. Performing lab, configure tests in LIMS, to enable them to work with NPEx. This may involve

amendments to the test setup with regards to interface mapping.

10. Sending lab, map tests in NPEx. Using the ‘test mapping template’ spreadsheet as a guide. Ensure

all specimen types are mapped.

11. Sending lab, map tests in LIMS. Ensure a test field is available for all results being returned by

performing lab, along with any interface configurations required to link tests with NPEx.

12. Test exchange. A recommended testing strategy may include:

Demographics testing:

Understanding the demographic mapping algorithm between NPEx and local LIMS.

Changing patient demographics after requesting but before results return.

Understanding how patient matching exceptions are handled in the LIMS.

Ensure all inbound requests are accepted into the LIMS; if they are to go to an exception queue

confirm how this will be managed.

Analyte testing:

Boundary testing’ (testing the upper and lower limits of result or comment fields).

Dealing with non alpha-numeric values (such as special characters).

13. Pipe Cleaning & UAT documentation. With the interface built, Pipe Cleaning with NPEx can

proceed wherein the laboratory does some testing with NPEx themselves as a Test Laboratory. This

should be a brief check that requests can file out and results file back without too much attention to

detail other than establishing the interface works (refer to section 2.2 of NPEx_Example_Pipeclean

document). Once pipe cleaning is completed then the laboratory can begin testing with a partner

board in their respective test (or demo) environments linked with the NPEx test environment.

Upon completion of Pipe Cleaning & User Acceptance Testing complete X-Labs Pipe Clean and UAT

documentation.

14. Verification testing. Complete Interface verification documentation with reference to ISO15189 (see

example ‘Verification of NPEx Board to Board Test Exchange’).


Page 11 of 22

5.3 Build and Configuration- Live Environment

LIVE environment testing focuses on Clinical and Operational testing. Interface verification has already

been achieved in User Acceptance Testing (UAT). At this point working in the live environment will

require some operational considerations; please make staff aware that dummy records will appear in work

lists or authorisation queues. It is worth walking though some of the dummy tests performed with users

from request (including order comms) to final result to see what operational impact this might have and is

also a good opportunity to streamline practices to enhance the impact of using NPEx.

[11] Contact Testing LabAgree initial tests

Interface Test Verification Workflow LIVE Environment

[12] Performing LabConfigure Tests in NPEx

[13] Performing LabConfigure Tests in LIMS

[14] Sending LabMap tests in NPEx

[15] Sending LabConfigure Tests in LIMS

[16] Testing Test Parameters Demographics Test Value boundary testing Unexpected values Unit of Measurement Reference Ranges Comments Clinical DetailsAll filings correct þ

[17] Complete Lab Verification

Document

LIVEEnvironment

[10] Ensure site to site configuration set up in NPEx


Page 12 of 22

15. Site to site configuration and My Lab setup. In ‘Site to Site Config’, ensure the Local Board LIMS

is configured in NPEx along with the partner site LIMS and department level disciplines. In ‘My lab’

setup, ensure the Lab name identifies both the Hospital AND the Town/City, for example Glasgow

Royal Infirmary. Also a general phone number and email address for NPEx related enquiries. In

addition, the ‘Result Behaviour’ setting can be configured to the local requirements, such as adding

the analytical lab name to all results.

16. Agree LIVE tests. The test list chosen should be agreed with the Performing lab. It is

recommended to select a group of tests that covers the majority of work being sent to a single

performing lab, which must include any reflex tests. The test list must ensure that no tests would be

‘split up’ in the sending lab between electronic (NPEx) and paper requesting.

NOTE: ALL tests resulted by the performing lab MUST have a corresponding result field in the

sending lab.

17. Performing lab – configure and map tests in NPEx. The NPEx catalogue has a comprehensive

list of tests already available. However if a new test is required, this can be built by X-Labs.

SNOMED codes can be used to assist with the test selection. Once mapped, the NPEx test details

and SNOMED code (if available) should be added to the Excel ‘test mapping template’ spreadsheet.

18. Performing lab, configure tests in LIMS, to enable them to work with NPEx. This may involve

amendments to the test setup with regards to interface mapping.

19. Sending lab, map tests in NPEx. Use the ‘test mapping template’ spreadsheet as a guide. Ensure

all specimen types are mapped.

20. Sending lab, map tests in LIMS. Ensure a test field is available for all results being returned by

performing lab, along with any interface configurations required to link tests with NPEx.

21. Test exchange, A recommended testing strategy may include:

Demographics testing (a smaller version of the UAT testing to cover the following):

Understanding the demographic mapping algorithm between NPEX and local LIMS.

Changing patient demographics after requesting but before results return.

Understanding how patient matching exceptions are handled in the LIMS.

Ensure all inbound requests are accepted into the LIMS (or if they are to go to an exception queue

– how will this be managed).

Analyse testing (recommended approach):

Test each set once on its own with the referring lab.

Test each set in a number of logical groups, along with any internal Order Communications

Bulk test the system, replicating a day’s worth of requests from the sending lab.

Test amended sets and amended comments.

Test result comments.

A minimum number of tests should be carried out with any new set from any new LIMS.

NPEx results should be compared to the original resulting procedure for a period of time


Page 13 of 22

22. LIVE Lab verification documentation – this should be completed and signed off by Clinical /

Laboratory staff with reference to ISO15189 (see example ‘Verification of NPEx Board to Board Test

Exchange’, provided as separate document).

Stage 3 Outcomes:

ID Outcome Checklist þ

6 Performing and Sending lab configured in TEST NPEx.

7 UAT test list agreed between performing and sending lab.

8 Test list mapped in NPEx by performing lab.

9 Test list configured in performing lab LIMS to work with NPEx.

10 Test list mapped in NPEx by sending lab.

11 Test list configured in sending lab LIMS to work with NPEx.

12 Comprehensive Interface testing in the TEST / DEMO environments with

agreed test list.

13 X-Labs Pipe Clean and UAT documentation completed and signed off.

14 Lab / Lab IT verification testing documentation completed and signed off.

15 Performing and Sending lab configured in TEST NPEx.

16 LIVE test list agreed between performing and sending lab.

17 Test list mapped in NPEx by performing lab.

18 Test list configured in performing lab LIMS to work with NPEx.

19 Test list mapped in NPEx by sending lab.

20 Test list configured in sending lab LIMS to work with NPEx.

21 Comprehensive testing in the LIVE environments with agreed test list.

22 Lab verification testing documentation completed and signed off.


Page 14 of 22

6. Stage 4 Operational Deployment

6.1 Operational Go-Live

The below workflow summarises the final stages to be completed before NPEx can be introduced into

normal working practice. Consideration should be given to the operational roles within your department

that are relevant for NPEx implementation, for example there may be reception staff sending and/or

receiving samples through NPEx, clinical staff who may review test results inbound/outbound as well as

those with administrative oversight of the NPEx system. When producing the documentation and training

outlined below think about what their interactions with NPEx will actually be. There may also be other staff

who may not interact with NPEx but need to be aware of its implementation. All these staff groups and the

likely members in them should be identified and the communication of the go-live process to them begun

well in advance before the introduction of NPEx.

[18] Create or amend pre existing SOP

[21]Complete Competencydocumentation

[22] Go Live Communications

Operational GO LIVE Workflow

[20]Training Lab Staff

[23] Operational GO LIVE

[19] Create Training Plan

23. Create an SOP (if you already have an SOP add the NPEx stages into the relevant pre-

existing SOP). Consider both reception procedures and any changes to clinical validation

processes and include a contingency element in the event NPEx is down. SOPs may be

divided up according to NPEx user role – e.g. reception, clinical and administrative roles.

24. Training plan – Create training plan for NPEx users by identifying training needs based on

how roles will be assigned and incorporate key elements of role into training plan. Consider

how training will be delivered and then cascaded to new NPEx users.


Page 15 of 22

25. Create user roles in NPEx - all users should be assigned appropriate user roles in NPEx and

their login credentials disseminated prior to training.

26. Training of Lab staff – train all relevant staff, identified by role as indicated above.

26. Competency documentation. Provide competency documentation for each staff member

using NPEx wherein their ability to perform each relevant aspect is recorded and signed off.

This should go hand in hand with the training plan.

27. Communication with Lab staff re go-live. Keep staff up to date on when the system will go

live and work with departments to support them to ensure they are prepared for this. Establish

a date that both laboratories can provide resource to support this with enough resource to

audit the results. It is improbable that when going live all tests exchanged between the boards

will be built, tested and verified so consider the impact of a mixed system being present on

workflow.

28. Operational Go-Live. On the day staff should be vigilant for any issues and it is

recommended that the same protocols in stage 22 Live Lab verification documentation is

followed so NPEx requests are checked for correct transmission of patient demographics and

results.

Stage 4 Outcomes:

ID Outcome Checklist þ

23 SOPs completed.

24 Training plan complete.

25 Training complete.

26 Competency documentation complete.

27 Communication to department complete.

28 Live with NPEx.


Page 16 of 22

7. Contingency

Document laboratory contingency processes in the event of significant operational issues or break in

NPEx service e.g. existing manual systems, ensuring manifest can be used as a request form.

Results can be sent back via original mechanisms (email / post).

8. Documentation

The following documents are provided for reference and quality purposes and can be obtained from the

Regional Project Manager. They have been constructed as far as possible to meet ISO15189:2012

(Requirements for Quality and Competence), particularly in reference to sections 5.4.3 Request Form

Information and 5.8.3 Report Content for the verification template.

1. NPEx User Guide 2017 v1.

2. NPEx Interface Issue & Change Log v0.1

3. Test Mapping Template v0.1

4. NPEx_Example_PipeClean_20181023

5. NPEx_Example_UAT_20181023

6. Verification of NPEx Board to Board Test Exchange v0.1

The User Guide is published by NPEx and provides an overview of their application and is a useful

reference document. The NPEx Interface Issue and Change Log can be used from the very start of the

interface testing and updated continually as amendments and changes to the interface or updates to

NPEx are made. When proposing tests for exchange between boards the Test Mapping Template is a

useful document that can be circulated to relevant staff for oversight as well as a progress record when

building new tests. The NPEx Example Pipe Clean and UAT documents are distributed to new NPEx

users and in conjunction with the Verification of NPEx Board to Board Test Exchange can be used to

verify the initial interface testing. The latter document can also be used for subsequent test builds as the

board’s repertoire increases.

Suggested documents (not provided)

NPEx Laboratory Reception SOP

NPEx Super User SOP

NPEx resulting and reporting SOP

Training and Competency documentation

9. References

Medical Laboratories – Requirements for Quality and Competence (ISO 15189:2012). BSI Standards

Publication.


Page 17 of 22

Appendix 1 – Setup

User Experience – Lothian requests to Glasgow Royal Infirmary (GRI) Biochemistry

LIMS Interface Considerations

Which field(s) to use for Clinical details? Ideally a large number of characters should be able to be

sent/received.

Demographic mapping – which fields will be mapped to send/receive with NPEx? Are these fields

consistently the same in the sending and receiving LIMS?

NPEx Considerations

The NPEx interface sends all of the requestor information to the local LIMS. NPEx cannot yet fully map:

Purchase order number

Urine volume

Fasting status etc

This is due to limitations with the sending and receiving LIMS systems.

NPEx Manifest Setup (Receiving labs only)

The NPEx manifest is essential to the booking in process. The manifest contains a Shipment ID which

contains all of the information about the sending lab, receiving lab and mapped tests. The default manifest

allows up to 5 specimens to be printed on one page, along with:

Sending Labs number

Patient details

Test/Specimen details

Receiving lab barcode space (to add the barcode on receipt)

The manifest is customisable and GRI Biochemistry has made the following changes:

Print only one specimen per page – to assist splitting/stabilising the specimens in the lab

Sending Labs number – added a barcode format to assist data prepping from the manifest

Clinical details – until the full clinical details are mapped to Specimen NotePad in TPATH, they will

print on the Manifest and the form will be scanned (as per all other paper requests)

Patient details – added for contingency

Patient address – added for contingency

Manifest Comments – to allow any comments relevant to the whole shipment

Specimen comments – allows urine volume or other relevant sample information (eg PO number)

to be added in to NPEx, although this field is not mapped to/from the LIMS.

NPEx My Users

NPEx has three levels of users: Administrator, Technician and User, whose roles are locally definable.

GGC Biochemistry has agreed to follow the same configuration setup:

Users – Entry level, for the majority of staff including A&C and Clinical Scientists. Users will be able to send and receive shipments and look up results.

Technician – Medium level, for supervisor and senior lab staff that may be required to have additional functions such as re-setting passwords, creating new users and cancelling requests.

Administrator – Highest level, limited to a small number of Labs and Labs IT staff that may be required to do build and system configurations.


Page 18 of 22

NPEx Site to Site Configuration – Receiving Labs

NPEx has two levels of site configuration: LIMS and Department. If there is only one department in a

given LIMS, then only one high level code is required. However, if there are multiple sites within a LIMS

(such as multiple Biochemistry labs within Lothian and Glasgow), each lab needs to be identified with a

unique code, to determine where the samples are being received from.

Note: In DXC TPATH, all location codes also need to be made ‘HISS reportable Y’. There may be an

equivalent in other LIMS.


Page 19 of 22

Appendix 2 – Workflow


GRI Biochemistry Workflow – Incoming work

Pre NPEx

The work being received by GRI Biochemistry is complex and requires a lot of involved handling in the

reception process. This information informed the decision as to how to set up the GRI Lab in NPEx.

GRI Biochemistry laboratory performs a number of specialist assays. The work is received by post along

with a paper request form (either hand-written or printed). The work is initially processed in the laboratory

reception, which may involve splitting of samples (for example a Nutrition Screen requires 4 specimen

types to be split into 9 tubes for different analytical platforms). Once the samples have been

split/stabilised and bar-coded, the samples are put into the appropriate storage location pending analysis

and the request form is passed to clerical staff to then data-prep the request into TPATH, the Laboratory

Information Management System (LIMS), which includes the referral lab, address and lab number, along

with the tests required. The forms are then scanned so that any clinical details on the form are available to

the reporting Biochemist when the results are finally authorised.

Post NPEx

The Shipping Manifest will replace the paper request form. GRI reception staff will sort the specimens into

relevant specialties. The samples will be split/stabilised and bar-coded as appropriate. Any relevant

sample comments will be written on the Manifest as per previous manual request form (for example

‘sample leaked’ or ‘insufficient’ etc).

Manifest forms will be passed to Clerical staff for data-prepping directly into NPEx. Any comments or

relevant details (such as urine volume) will then be updated directly into TPATH.

Note: The NPEx process has aligned to the previous manual process as much as possible.


Page 20 of 22

Appendix 3 – Testing Plan


Testing Plan – Incoming work to GRI

For each site that goes live with NPEx, the following processes will be carried out:

Confirm the sets (including site of analysis) that the sending lab refers to Glasgow

Determine if these sets are already live in NPEx for Glasgow

Build each of the GGC Lab sets in NPEx (Labs IT staff required, if not already built)

Test each set once with the referring lab

Test each set in a number of logical groups, along with any internal AUCOMs

Bulk test the system, replicating a day’s worth of requests from the sending lab

Test amended sets and amended comments

Test result comments

Test extreme high and low results, NA’d results and any other plausible options.

Testing Partner – Lothian

Lothian currently have an NPEx connection with Grampian, for work going from Grampian to Lothian.

Lothian was chosen to be the first testing partner for Glasgow. Lothian refer work to GRI Biochemistry for

33 analytes (see appendix 5).

Amending Results and Add-On Tests

NPEx supports the amendment of results and adding on tests, however this must involve communication

between the reporting and receiving laboratory as the authorisation status of a sample may not allow filing

of amended results. As an example Glasgow performs a test for Lothian and the result files to Lothian’s

LIMS and is rapidly fully authorised. Staff in Glasgow amend the result but the result will not file to

Lothian’s LIMS.

Arrived / Missing / Damaged / Ignored

Tests booked in through NPEx can be categorised as either; arrived, missing, damaged or ignored.

Arrived is used when the specimen request is booked normally and filed to the receiving lab’s LIMS.

Missing and damaged both send a notification visible in NPEx only and subsequently cannot be booked in

to the receiving lab’s LIMS. Lothian and Glasgow do not use this feature. Missing or Damaged

comments are instead added to the LIMS so there is a complete audit trail of the event. Ignored is used to

essentially hold the specimen request until it can be assigned one of the other 3 statuses.


Page 21 of 22

Appendix 4 – Issues


Tests not requested, but part of the result.

There are a few tests not specifically requested by Lothian, but are reported as part of a set of tests from

GRI. For example, Lothian measure testosterone locally; however GRI measures testosterone as part of

the ANDRO profile.

Outcome – GRI has taken the decision to map all test results to NPEx and it will be up to the referral lab to

take any of the results they have not requested. Lothian have created suppressed tests in APEX so the

results are viewable internally by lab staff. For example, Lothian now has two testosterone tests – the

internal one and a “send-away” once. This also applies to urine steroid profiles, with all tests results along

with an overall comment set interfacing with NPEx.

CRP requesting for Nutrition Screens

GRI routinely measure CRP with any manual request for a ‘Nutrition Screen’, whereas if STEMDRL tests

are requested as a list/separately, no CRP is added. There is no simple mechanism of having a ‘Nutrition

Screen’ in NPEx as GRI provides different screens based on the Location of request.

Outcome – GRI will measure what is requested. If a sending lab would like CRP analysed, then this will

need to be requested. One site has created a non-reportable ‘Glasgow CRP’ test to receive this result.

Test Build

NPEx has a test catalogue of analytes that are already in use by other labs. A test can be searched for by

either name or SNOMED code. If a suitable test name is not available, a request can be submitted to

NPEx via the Remedy on Demand (RoD) system. These are usually built within 24 hours of the request

submitted.

GRI has used a relevant name where available, however if a different (non-serum) specimen type is

required (such as blood cadmium) then a decision was taken that this should be clear in the test catalogue

name. If no specimen type is mentioned then it is assumed to be serum.

Demographic Mis-match

Testing highlighted that if there is a miss-match with a CHI (primary TPATH identifier) and name then

TPATH will not accept the result. The order looks to have been accepted in NPEx; however the order

does not come in to TPATH. The issue was traced back to the ARES interface configuration. This was set

to ‘Error’ when the CHI and name did not match. It was agreed that this setup must be changed. The

implications for Labs of no change are that work will be missed, with no notification in any realistic time

frame.


Page 22 of 22

Appendix 5

Test Catalogue: Work sent from Lothian to GRI Biochemistry

Set GRI Set Name NPEx Name

1 125VTD 1:25-diOH Vitamin D 1,25-dihydroxy vitamin D

2 24USP 24hr u steroid prof 24 Hour urine steroid profile

3 AMH Anti-Mullerian Horm Anti-Mullerian hormone measurement

4 ANDRO Androgen Screen Testosterone

Androstenedione

17-hydroxyprogesterone

5 BS17HP Blood spot 17OHP Blood Spot 17 Hydroxyprogesterone measurement

6 CALC Calcitonin Calcitonin

7 IGF1 IGF-1 Serum insulin-like growth factor 1 measurement

8 USP Urine steroid prof Random Urine Steroid Profile

9 VITDT Vit D (D2 D3 Total) 25-hydroxy vitamin D (D2, D3 and Total)

10 APOA1 Apo A1 Serum apolipoprotein A-I measurement (procedure)

11 APOB Apo B Serum apolipoprotein B measurement (procedure)

12 LPA Lipoprotein (a) Lipoprotein (a) measurement

13 ALU Aluminium Plasma aluminium level

14 BCAR Beta-Carotene Beta-carotene measurement

15 CAD Blood Cadmium Blood cadmium measurement (procedure)

16 CHRO Chromium Whole blood chromium concentration measurement

17 COB Cobalt Whole blood cobalt concentration measurement

18 COPP Copper Copper measurement

19 LEAD Blood Lead Blood lead level

20 MAN Manganese Whole blood manganese measurement

21 MER Mercury Mercury measurement, blood

22 PSEL Plasma Selenium Plasma Selenium

23 RCSEL Red Cell Selenium Red Cell Selenium

24 UAS Urine Arsenic Arsenic measurement, urine (procedure)

25 UCOP Urine Copper Copper measurement, urine

26 VITA Vitamin A Vitamin A measurement

27 VITB1 Vitamin B1/Thiamine Red Blood Cell Vitamin B1 level

28 VITB2 RBC Vitamin B2 Red Blood Cell Vitamin B2

29 VITB6 RBC Vitamin B6 Red Blood Cell Vitamin B6

30 VITC Vitamin C Vitamin C

31 VITE Vitamin E Vitamin E measurement

32 VITK Vitamin K1/PhylQ Serum vitamin K measurement

33 ZIN Zinc Zinc measurement

Documents

Stage 3 Build, Configuration & Testing Stage 4 Operational ......UAT User Acceptance Testing X-Lab Name of service provider 2. Background This guide is designed to support labs staff