Pathology Bound Code List and Its Replacement User Consultation V1.1 22/12/2015

Document filename: Results of Request Submission Portal User Consultation Directorate / Programme Architecture, Project Diagnostic Data Standards and Service Innovation

Document Reference Service Head Laura Sato Status Approved Owner Laura Sato Version 1.1 Author Kat Randle/Wendy Version issue date 22/12/2015 Tarbox

Pathology Bound Code List and its

replacement User Consultation

Document Management Revision History

Version Date Summary of Changes 0.1 27 October 2015 First draft 0.2 06 November 2015 Further update following development 0.3 13 November 2015 Diagram updates 0.4 04December 2015 Further updates 1.0 07 December 2015 Final update 1.1 22 December 2015 For approval

Reviewers This document must be reviewed by the following people:

Reviewer name Title / Responsibility Date Version Laura Sato Head of Diagnostics 07/12/2015 V1.0 Data Service Ian Arrowsmith Head of SNOMED CT 17/12/2015 V1.0 implementation Deborah Drake Terminology Specialist 17/12/2015 V1.0

Approved by This document must be approved by the following people:

Name Signature Title Date Version Head of Diagnostics Laura Sato 05/01/2016 V1.1 Data Service

Glossary of Terms

Term / Abbreviation What it stands for HSCIC Health and Social Care Information Centre IHTSDO International Health Terminology Standards Development Organisation LOINC Logical Observation Identifiers Names and Codes NLMC National Laboratory Medicine Catalogue PBCL Pathology Bounded Code List SNOMED CT Systematized Nomenclature of Medicine Clinical Terms TRUD Technology Reference Update UKTC UK Terminology Centre

Document Control:

The controlled copy of this document is maintained in the HSCIC corporate network. Any copies of this document held outside of that area, in whatever format (e.g. paper, email attachment), are considered to have passed out of control and should be checked for currency and validity.

Contents

1 Purpose of document 5

2 Audience 5

3 Scope 5

4 Background 5

5 Methodology 6

6 Results 6

6.1 About You 7 6.2 Previews to Releases 9 6.3 Release Format 12 6.4 Implementation Timescales 15 6.5 Terminology Coding Standard 23

7 Conclusion 31

7.1 Previews to releases 31 7.2 Release format 32 7.3 Implementation Timescales 32

8 Recommendations 33

8.1 Previews to releases 33 8.2 Release format 33 8.3 Implementation Timescales 33 8.4 Terminology coding standard 33

9 Appendix A – Questionnaire 34

10 Appendix B - Organisations 34

11 Appendix C – List of respondents roles 35

1 Purpose of document

The purpose of this document is to describe the results of the Pathology Bounded Code List open user consultation conducted in summer 2015 which was to enable respondents to influence development, release and implementation schedules for future primary care pathology data standards. 2 Audience

This document is written as a summary of responses received in the questionnaire for all those interested in the overall questionnaire results. 3 Scope

This consultation was focused on the Pathology Bounded Code List (PBCL) in response to implementation queries and suggestions. The purpose of the consultation was to assist the safe and consistent implementation of pathology information standards across the NHS by identifying improvements in the PBCL update and implementation approach. It was designed to gain the opinions of laboratory, middleware and GP system suppliers and their users by asking about:  the potential for a draft standards review and discussion opportunity,  units of measure standardisation and Read code V2 (used in PBCL) withdrawal approaches  desired file format(s) for future releases of primary care pathology data standards. It is the intention of the Diagnostics Data Service that the results of the consultation should influence how the final PBCL release (scheduled for April 2016) and future primary care pathology results data standards are developed, released and scheduled for implementation for primary care results messaging.

4 Background

National standards for electronic communication of primary care pathology results data and message format have been used in England since 2002 for electronic communications between laboratory IT systems to GP IT systems. These standards, Read terms and codes and EDIFACT (United Nations / Electronic Data Interchange For Administration Commerce and Transport) message format are still in place today. Both are becoming increasingly unfit for purpose as they are limited in their ability to change and ‘keep up with’ rapidly-evolving clinical practice, data-sharing requirements and technical environments.

5 Methodology

An on-line consultation questionnaire (see appendix A) was hosted on Citizen Space from the 28th July 2015 to the 7th September 2015, all registered users of the PBCL and NLMC download packs available on TRUD were notified about the consultation by email. Awareness was also raised by articles placed on professional body journals during the consultation period. The questions were developed within the HSCIC Diagnostics Data Service and were based upon areas highlighted in previous feedback, stakeholder engagement and business analysis. The consultation was also reviewed by HSCIC communications experts to ensure it conformed to HSCIC guidelines. 6 Results There were 83 respondents to the consultation in total though not all questions were answered by every respondent. Respondents were given the opportunity to provide contact details if they wished to receive further communications on the consultation outcomes. 92% of respondents provided their name and 93% provided their email address The responses per question are summarised below.

6.1 About You 6.1.1 Question: What is your organisation? (optional) 90% of respondents provided their organisation type which separated out as noted be

16%

Primary Care

40% Secondary Care Supplier Other

21%

Key Option Total Percent of Responses A Primary Care 36 40% B Secondary Care 5 6% C Supplier 19 21% D Other 14 16%

The full list of organisations is in Appendix B.

6.1.2 Question: Which of the following best describes your role (Please tick all that apply)

5% 6% 5%

39% 5% GP IT system supplier LIMS supplier Middleware supplier Trust IT Manager Lab manager - Lab IT Other (please specify below):

40%

Key Option Total Percent of Responses A GP IT system 4 5% supplier B LIMS supplier 5 6% C Middleware supplier 4 5% D Trust IT Manager 4 5% E Lab manager - Lab 32 40% IT F Other (please specify 32 39% below): The majority of the respondents (53%) were from individuals whose current role was in Laboratory Medicine. The full list of roles (including those respondents provided in the ‘other’ category) is in Appendix C.

6.2 Previews to Releases 6.2.1 Question: Would you be interested in participating in an open online discussion forum about draft pathology data standards?

Key Option Total Percent of Responses A Yes 37 82% B No 8 18%

Of the 45 respondents to this question 82% were interested in participating in an open online discussion forum

6.2.2 Question: Would you be interested in participating in a national expert working group for projects such as primary care pathology data standards?

Key Option Total Percent of Responses A Yes 32 71% B No 13 29%

Of the 45 respondents to this question 71% were interested in participating in a national expert working group

Key Option Total Percent of Responses A Face to face 11 18.6% B Telephone 18 30.5% conferencing C WebEx (Desk-top 21 35.6% sharing) D No Preference 8 13.6% E Other (please specify 1 1.7% below): Respondents were able to provide more than one answer to this question. 66% of respondents preferred remote communications using technology with 36 % preferring desk top sharing and 30% telephone conferencing facilities. Email circulation was suggested as another working group format

6.3 Release Format 6.3.1 Question: Are there any other publication formats, for each pathology data standards release, that you would find useful?

Key Option Total Percent of All A XML & XSD (XMI 42 27.5% with Schema) B CSV / spreadsheet 59 38.6% C Web Service 12 7.8% subscription (ATOM / RSS feed) D Browseable HTML 39 25.5% (available online) E Other (please specify 1 <1% below):

More than one response was allowed for this question.

6.3.2 Question: Aside from the release itself, release notes and implementation guidance, would any other information about each release of PBCL (or its successors) be useful to you (for future inclusion within the release package)?

Key Option Total Percent of Responses A Yes 18 42% B No 25 58%

42 % of respondents identified they would prefer additional information to accompany the release note and implementation guidance

Additional information requested includes:  comprehensive update on changes and intended and actual impact assessments of these changes.  notice of forthcoming changes and topics under consideration.

 advice on the conversion of results which use different units of measurement (e.g. [Hb] g/L, g/dL, mmol/L), different assays (e.g. PTH), comparison of different methods for assessing the same biological attribute, particularly useful when changes to methods are made (e.g. coagulation and anticoagulation control), distinction between and labelling requirements/ability to combine similar sounding tests (e.g. calculated serum bicarbonate on an arterial blood sample submitted for ‘gasses’ and measured serum bicarbonate on a venous blood sample submitted for ‘U&Es’).  standard methods of correcting published but erroneous results and how to propagate these through the NHS.  Include adopted units of measurement for tests  Link to NLMC  project plan  Properly argued reasons for change  Reason for some of the changes, as many seem arbitrary, and assurance that changes especially deletions will not impact directly on GP systems with loss of long term history (see recent PSA code deletion).  Standardisation process, contacts change process etc  Summary of changes and developments, clear guidance on how to query, clarify, affect and validate standards.  The release notes need to contain a summary of changes and linkages  There have been problems recently in primary care with changes not been ready in clinical systems in time, e.g. the recent change to eGFR caused problems for many practices in Gloucestershire.  Tie in the recommended units with the recommended coding  Understanding of rationale for changes being suggested and implemented. Also a need for close working between the four GPSoC core system suppliers AND their respective User Groups to ensure that changes suggested din PBCL or successors do not lead to discontinuity and clinical risk to the GP Electronic Patient Record data flow/charting/graphing of results.

6.4 Implementation Timescales 6.4.1 Question: A key aspect of patient safety is the use of nationally standardised units of measure per test across all NHS laboratories. A lack of national standardisation of units of measure has caused clinical misinterpretation and patient safety risks and the use of different units for the same test makes it difficult to compare patient results between different laboratories (e.g. within a shared patient record or sometimes within the Primary Care record). This can lead to the same test being requested unnecessarily by different clinicians. Professional bodies are making a significant effort to set national standards for the unit of measure for each pathology test. With this in mind, please indicate below your minimum estimated timeframe for safely implementing (including clinical safety testing) a change to a unit of measure in your system(s)?

Key Option Total Percent of Responses A Two months 24 31.6% B Six Months 36 47.3% C Twelve months 9 11.8% D More than 12 months 7 9.2% (please specify below):

There were 76 responses to this question of which 47% felt that 6 months was a safe timescale for implementing changes to units of measure safely.

Respondents provided the following observations:  All Units of Measure (UoM) changes needs to be implemented in the same way as the Hb. National implementation across all laboratories on a timescale that is long enough for validation and testing to be carried out and the change to be communicated to all end users. The current situation is unacceptable.  Beyond our remit as LIMS / Middleware supplier.  Concern about methodology may not be applicable to chosen UOM- Need the ability to code output outside the agreed standard for a variety of reasons. Then lab non- conformance can be tracked and reasons captured.  has to be phased across primary and secondary care (LIMS) implementations  Technically it's not difficult it just needs scheduling in but there are occasions when we don't agree with the UoM agreed, sometimes the machine measures in one UoM and calibrates on it so to change it just to comply with a UoM that is being dictated doesn't go down too well. It has implications when we need to print results out from the analysers and phone them (the LIMS can convert easily enough) but we don't always have the LIMS and have to rely on the analysers. It's not as straight forward as you would think and I often have to remove the read code altogether because we can't comply with the UoM.  This is on the expectation that the code will be passed through  This is user configurable in our system  Two years (following our merge into a Pathology Partnership).  Would depend on whether or not changes to methods would need to be implemented, or if conversion factors can be used.

6.4.2 Question: The current implementation timescales for PBCL changes per release were established for a national data standard in ‘maintenance mode’, with relatively few expected changes per release. A report of an audit by NHS Connecting for Health on test reporting standards in electronic pathology messages sent to primary care (published in The

Bulletin of the Royal College of Pathologists in October 2012) identified serious issues with pathology results data using PBCL. As a consequence, the Royal College of Pathologists began providing national clinical governance over the content of PBCL. Following on from this a significant number of changes has already been requested and more are anticipated in future.

Key Option Total Percent of Responses A Addition 4 9.5% B Deprecation 13 31% C Neither / they’re 25 59.5% about the same

51% of respondents answered this question of which 59% felt that additions and deprecations took the same amount of time to implement safely. 31% of respondents felt that deprecating codes were more time consuming than adding codes. 6.4.3 Question: Using your local implementation experience, please indicate the time frame you consider reasonable for implementing the following number of terminology code additions:

Key Option Total Percent of Responses A One month 15 21.1% B Two months 20 28.2% C Three months 16 22.5% D Four months 6 8.5% E Five months 0 0% F Six months 7 9.9% G Other (please specify 7 9.9% below):

72 % of the 71 respondents felt that 50 additions could be safely implemented within a 3 month period

Key Option Total Percent of Responses A One month 5 7.2% B Two months 7 10.1% C Three months 22 31.9% D Four months 5 7.2% E Five months 2 2.9% F Six months 15 21.7% G Other (please specify 13 18.8% below):

81% of the 69 respondents to this question felt that 150 additions could be safely implemented within 6 months. The following comments were given to explain why other timescales were identified beyond 6 months. Several respondents provided the following comments:  Additions are easier, because they can be simply introduced via middleware.  Beyond our remit as LIMS / Middleware supplier.  Customer communication is rate limiting step  No experience of that scale of additions  number of additions / deprecations makes no difference to the computerised process.  They don't always apply to my tests so its dependent on what ones you are changing  This is a case of downloading a tool if one is available, the main work is for the labs to achieve.  This is user configurable in our system - timeframe user dependant  User configurable, time frame user dependent.  While it is straightforward to implement new terms and codes in modern agile systems, some old systems still require hard coding. This takes time and costs money which is not always available.

6.4.4 Question 12: Again, using your experience, please indicate the time frame you consider reasonable for implementing the following number of terminology code deprecations:

Key Option Total Percent of Responses A One month 13 18.3% B Two months 13 18.3% C Three months 17 23.9% D Four months 8 11.3% E Five months 2 2.8% F Six months 8 11.3% G Other (please specify 10 14.1% below):

85% of the 71 respondents to this question indicated they could safely deprecate 50 items within a 6 month period.

Key Option Total Percent of Responses A One month 3 4.3% B Two months 9 12.9% C Three months 13 18.6% D Four months 9 12.9% E Five months 0 0% F Six months 23 32.9% G Other (please specify 13 18.6% below):

70 respondents provided an answer for 150 deprecations. Of which 81% indicated they could safely implement 150 deprecations with six months. However 5 respondents indicated they would need 1 – 2 years. It was acknowledged by two respondents that they do not have experience of this scale of deprecations. A number of respondents provided the following comments  it's dependent on what the new/old codes are  Availability of a suitable alternative that is compatible with lab method is rate limiting step, can take a few months or not be possible under current analyser platform. GPs clinical history for the same test becomes fragmented.  Beyond our remit as LIMS / Middleware supplier.  it all depends how many deprecations already coded you have  min 6m for any deprecations unless specific urgency for any one term  No experience of that scale of deprecations  Removals mean it is necessary to first delete existing links, and rebuild new ones, plus communicate these changes to GP users.  so long as full info supplied  The time also covers distribution to each clinical system in the GP estate.  user configurable in our system - timeframe user dependant  While it is straightforward to implement new terms and codes in modern agile systems, some old systems still require hard coding. This takes time and costs money which is not always available.

6.5 Terminology Coding Standard 6.5.1 Question: Please provide any input or feedback for the above possible roadmap, e.g. in terms of its feasibility, whether the assumption for the transitional specification is correct, whether the timelines are reasonable, etc.

Content Assumptions Version Implementation Date / timescale

A PBCL in Read v2 Read PBCL’s final 8 weeks from release publication (current timescale is 6 weeks)

B PBCL content in Change restricted to Transitional Spec 1 January 2017

SNOMED CT SNOMED CT (8-9 months’ notice)

C PBCL concepts in LOINC is generally Transitional Spec. June 2017 NLMC, to include more specific than Replacement (14-15 months’ notice) SNOMED CT and PBCL and this LOINC to replace publication may also the Transitional include new Spec. microbiology results coding

From 83 customers 56 provided the following feedback, which have been grouped by general topic:

6.5.1.1 Time 1. The time taken to implement the changes will depend on how comprehensive the list is. In many cases the code expansions don’t adequately describe the test being performed e.g. XYZ level when a qualitative test is performed and the use of the test RAST for allergies instead of Specific IgE 2. It is feasible to achieve these timescales, but it depends on the amount of involvement between the multiple groups involved and the amount of centralised management of the project. Without clear timescales and regular interaction, this will get left as a thing to do at the last minute, and instead of being a useful and improved methodology, it will appear as another change that people will neither appreciate nor feel was necessary. 3. The timescale would be reasonable but some LIMS systems would need to alter their formats to allow the addition of SNOMED CT codes. Not currently feasible with iLab TP (CSC) which would be the stopping point for our laboratory. 4. I don’t have an issue with proposed timescales 5. Translation to SNOMED CT would be done by LIMS suppliers I presume. If LOINC is to be implemented then the time scale would be very challenging: every laboratory will have to field a representative for each discipline and these people cannot be spared at present. 6. For laboratories that employ a relatively modern LIMS system this may not be a problem, however, some laboratories still use somewhat dated systems which may not have the functionality to readily adopt the new coding systems. These laboratories may require additional time to implement, especially if this programme stimulates them to replace their current LIMS with a new one and the procurement and implementation times that will create will have to be factored in. Another factor will be the necessity to ensure that any changes in the coding systems in the laboratory's LIMS meets ISO15189 standard 5.10.3, which in itself may require additional time to ensure that appropriate document changes are made and signed off and that any changes to the respective LIMS systems has been validated in a way to meet the ISO15189 standards. 7. December 2016 seems an artificial date and one that is most at risk. If we mean before Christmas, should we not aim for November 2016, and if we mean after Christmas/New Year, should we not use Jan 2017? 8. I view the roadmap as highly speculative and unachievable in my environment.

9. Timeline is reasonable but smooth transition depends on primary care system providers also keeping to the expected timeline.

 While I personally support the roadmap, implementing this at speed and in the timescales set out requires better understanding of the issues in most labs.

 We are happy with the above timeline as long as the Pathology Clinical System provider is in agreement.

 The timescales seem reasonable  Road map is pragmatic and the timelines are reasonable.  The above timescales appear achievable, however, any change or possible movement of these timescales or if a change to the content is considered, an announcement made regarding this at the earliest possible time to allow for feedback, would be beneficial for timely development and testing of the change.  This will need more detailed consideration about the technical impact and how it can be included within our existing roadmap.

6.5.1.2 Content 1. PBCL yes, unable to comment on SNOMED or LOINC An interesting approach however has anyone done any work on producing a pre coordinated set of codes to see how big the list will be? My understanding from speaking to colleagues working in Labs, particularly in micro-biology, is that there are so many combinations that it would produce a completely unworkable list. I understand that when NLMC was being developed that this was considered and a decision was made to go for post-coordination. So has this been reversed? And the whole premise behind SNOMED CT, and CTV3, was that post-coordination is necessary otherwise the list of terms/concepts becomes too large. Everyone needs to accept post-coordination rather than continually avoiding it. 2. I do not know enough about LOINC to comment accurately; pre-coordinated SNOMED CT terms are essential. There is a great deal of work to do! 3. The catalogue, coding and UOM work goes so far, what is missing is the metadata that shows what actual test was done, what machine used and what reagents used. For some tests that would aid comparison of results and for others prevent erroneous comparison. 4. If this is to include units of measure then need to consider this:  if a supplier continues to refuse to file units as sent by a laboratory then cannot have phased approach to implementation everyone must change on same day (that is all GP practices and all laboratories). 5. Does UK Primary Care really need LOINC as well as pre-coordinated SNOMED-CT? 6. The transitional specification is an additional layer of complexity that could be potentially confusing. I am very concerned that the software capabilities of some GP systems can be challenging. These 2 issues could unravel the aspirations. 6.5.1.3 Development approach 1. The overall roadmap is sensible, but one wonders how feasible PBCL content in SNOMED CT in Dec 2016 is. December is never the most productive month, and if we really mean before Christmas perhaps we should aim for Nov 2016 or Jan 2017.

2. It would be best if the old and new systems could be built side by side, with ability to run new system as a "dummy" to a local server to check the integrity against the current PBCL system. 3. I think this is going to be dependent on where you currently do your mapping of codes. Those who do it natively within the LIMS may need more time than those who do the mapping in the middleware. I make this judgement based on the fact that the middleware suppliers tend to have quicker development cycles, and because upgrades require less comprehensive testing. 4. If detailed information is provided on how to make these significant changes, how these can be tested in a live environment and time is given to do this as we all have day jobs as well then the timescales appear tight. It also requires the clinical suppliers and GP system suppliers to help in making this happen. 5. Entirely dependent on LIMS supplier and/or middleware being converted, what that looks like, and whether there will be costs associated, and requirements for testing. 6. This questionnaire has come to me twice on two email addresses. I am not convinced that the first questionnaire captured all of my responses. I would be interested in joining on line discussions about pathology standards and also expert group. 7. This seems sensible and achievable but would, of course, be carefully monitored/ reviewed during the process. You should not be afraid to alter timescales one way or the other during the process - there is no shame in that! I am a revalidated Consultant Haematologist with general clinical and laboratory experience, having always taken an interest in these sorts of issues in conjunction with BMS staff. I am not an IT expert! 8. I think this is a really valuable piece of work, whilst it is mainly centred around the labs, I would be happy to be contacted if you need any specific input from primary care. 9. If the new catalogues are well consulted and do have a wide enough array of specific terms to cater for 99% of analytical platforms then this timescale is ambitious but feasible. If too many terms are missing, and lab leads cannot find suitable terms for the assays they provide, then they will either fail to meet the deadlines or go-live at risk with significant proportion of uncoded terms. 10. Quality and breadth of the catalogue is key. Any compromise will need to allow labs to decline to apply a specific term but still effectively operate in the meantime while the technical discussion on each point of contention commence. Please don't leave the labs without options to fulfil their primary function! It is more dangerous to not convey a patient result at all for lack of specific coding term. It is even more dangerous to insist that an administrator, external to the lab, can locally pick a coding term that the lab felt unsafe, simply to allow a result to be processed. 11. Have CSC (iLab LIMS) been involved in this consultation and what was the response.

6.5.1.4 Resource 1. Most laboratories only have a few staff familiar with PBCL and its implications and maintenance, hence too rapid a transition will inevitably result in loss of data/system integrity.

2. Will require significant additional resource to migrate from PBCL, and unless this is to be incorporated deep into LIMS, then long term security and maintenance will be extremely problematic 3. Also noted that the expertise within GP practices is even more limited/restricted, hence a major input here will be required. 4. Would be feasible if it were my only task. Unfortunately that just could not happen so I have no idea how I would manage to get this done. 5. Speaking from a laboratory IT perspective, the first consideration is the actual resource impact of the required changes. A Pathology laboratory has a test repertoire of approximately 7000 with additional battery/set considerations. All changes will need to be done across the whole test repertoire on a test by test basis and the overhead will be significant

6.5.1.5 Coordination 1. Any changes must include consultation with GP system suppliers to ensure that any changes will provide a backward compatibility. For example: a patient with a history of diabetes has a number of observations for HbA1c, any change MUST ensure that this history is retained and available to the GP in a clearly understandable format. We must avoid a situation like the recent mandated removal of a PSA code which means that the patient record has two groups of results which are not linked. 2. My only query would be what impact if any there would be on the Scottish Boards. As you may be aware we have used the READ coding to code tests and allow information presentation across Boards. With the proposed withdrawal of the READ codes in 2017 is there an expectation that Scotland will also move across to SNOMED-CT or similar? 3. As with many national changes, the system suppliers are going to be the rate limiting step as the actual implementation and maintenance consequences at the diagnostic laboratory side are often hard to estimate until the functionality is available to us. 4. A significant period of time is required for the lab reporting system to change over to SNOMED. The way our system currently works, the catalogue cannot be implemented in the laboratory until all surgery systems are SNOMED compliant. We cannot pre-prepare SNOMED codes, in that we cannot have the exact same test and specimen type coded in two different formats i.e. a test is either coded in V2 or in SNOMED, but not both. The changeover would then require a month or two to start to replace Read V2 codes with SNOMED codes - this process would be made significantly quicker if there were a cross-map between Read V2 and SNOMED. During this time READ V2 tests would still be reported, while they are changed one-by-one to their SNOMED version. 5. From a suppler perspective the road map and timescales are feasible; it will however require significant reconfiguration and end to end testing on a per site basis. In the event that not all result recipients (GP’s) have moved to the same coding structure thought will need to be given to how each LIMS caters for a mixed economy of coding being required in both PBCL and LOINC/SNOMED 6. The next consideration is where the actual coding will be physically done. Currently, my LIMS does not have the facility to assign any additional codes to the result

message; this is done in the middleware solution (currently Indigo Keystone). If my supplier cannot provide this functionality, I cannot comply with these changes! In summary, the proposed timescales are extremely worrying as there has, to my knowledge, been no direct engagement with laboratories to assess the potential impact these proposals will have or whether they can actually meet the deadlines. Add to that the fact that no supplier has, as yet, anything in place to be able accommodate these changes from a Pathology result message perspective, there is serious risk. 7. One question is how do we keep it all in sync between suppliers for a migratory path, that is a very small ask! PMIP for middleware was a 2 year project and that didn’t take into account two releases a year. Path labs themselves cannot even get to achieve PBCL in the latest round of updates.

6.5.1.6 Changing standards 1. How are Pathology expected to provide diagnoses codes in their messaging to GPs? And order comms systems (Sunquest ICE), are they going to be coordinated to provide diagnosis codes? I do understand that at a basic level all Pathology requests can be thought of as two parts 1) a question ( what is the sodium level, is there an infection in the urine 2)a context (change in renal function, abdo pain). 2. If this rather simplified system of thought can be of any use to the group who are considering these changes then I'd like to know and be a part of any discussions. 3. I need to understand a little more of what is proposed before I can comment on assumptions/timelines. 4. I really have no experience of implementation of these changes, I simply know that the current system of READ codes are not remotely fit for purpose; there is far too much duplication alongside significant areas where codes are lacking. Those who control the system have inadequate links with those on the ground. I have only had a quick look at SNOMED and LOINC. My main point would be to be assured that the system will include all possible UK terms. For example, the antibiotic fosfomycin is available in IV formulation within the UK but SNOMED only mentions the oral formulation. 5. Clinical systems may not be able to store concurrent coding sets and re-issuing of reports and translation of historical terms could be a significant issue here. 6. I'd support the use of LOINC if this is demonstrated to be more comprehensive as described though suggest the migration to this would be one step from Read to LOINC for pathology terms if that is what the objective and standard is? 7. Some practical clarifications required here including where the NLMC fits in Can only plan to change so much at any one time and the concurrency of code sets worries me here as does the practical impact to sites and GP systems etc. 8. Our NHS customers currently send lab results using Read Codes and HL7, versions 2.3, 2.4, and 2.5. 9. It's not clear how the additional data associated with SNOMED codes will be sent using HL7 2.x, whether this is even feasible, or whether moving to an alternative messaging format will be required.

Switching from HL7 2.x to another messaging format will require significant effort and cost for laboratories, Trusts, and suppliers such as ourselves. This raises the issue of how these changes will be funded and whether there is an appetite for such a wholesale change. Assuming it is possible; accommodating SNOMED data within the existing HL7 2.x messaging infrastructure is likely to result in more achievable changes and therefore quicker and more widespread adoption. 10. This looks reasonable. NLMC is the preferred system due its' bespoke design for such use. LOINC was developed as an order comms system, not a nomenclature standard. 11. There is little or no experience to date of LOINC in the GP domain which therefore makes it very difficult to comment on the feasibility of this roadmap. I would remain agnostic at this stage and would hope that before we go any further a suitable group of domain experts could get together and agree the clinical requirements and then seek the solution that can best meet those requirements. Whether that would involve SNOMED CT pre-coordinated / post co-ordinated, or some combination of SNOMED CT and LOINC, or perhaps use of pre-coordinated SNOMED CT - with suitably devised archetypes, or some other solution I would not at this stage wish to predict. 12. Our current LIMS is I. Laboratory (Apex) from CSC. The core software is now over 22 years old. It supports using READ v2. Changing to READ v3 (used by TPP SystmOne) would need some code change. Changing to SNOMED CT and/or LOINC would require major software revisions. Have HSCIC obtained any confirmation that CSC are able to implement the necessary changes by the dates in the proposed roadmap? 13. I appreciate the need for migration to SNOMED-CT. But is it really essential to duplicate this with LOINC? Please refer to the relevant work streams of the National Information Board '2020: Framework for Action'. The potential for confusion and patient safety issue is high if there is a parallel pathology coding structure. This needs to be re-visited - and needs to have close conversation from now with the four core GPSoC Primary care Clinical System suppliers (EMIS, Vision, Microtest and SystmOne) AND THEIR RESPECTIVE USER GROUPS (e.g. EMIS NUG, VNUG, SNUG). The RCGP Joint GP IT Committee (JGPITC) all needs to be involved in this discussion.  It would be useful to clarify the difference between the existing NLMC content at: http://www.rcpath.org/clinical-effectiveness/pathology-catalogues/national- laboratory-medicine-catalogue/national-laboratory-medicine- catalogue.Including the summary from the President of the RCPath 2009 and what is now described as the NLMC. Is the term ‘NLMC’ being retained but the content changed? Will the scheme adopted apply to: results being reported to primary care (even if the tests were done in hospital on an inpatient or outpatient)

reporting of results requested in primary care (even if they are reported to hospital systems)  results requested in and reported to secondary care  all four home countries or just to NHS England? 14. Our strategy for a number of years has been the integration of SNOMED CT into the underlying EMIS architecture. This has been designed into the system. I would advise at this time that a move to LOINC may jeopardise the stability of complex systems as pathology results will be evaluated within protocols, decision support algorithms and data extracts. Careful consideration would be required to consider how to meet the basic requirement of representing the identifiers within database tables designed to work on a single terminology model. At the present time I am unable to offer any support for the LOINC proposal. As an organisation we are working to achieve SNOMED CT (with PBCL) migration within EMIS Web systems by 1st January 2017. 15. To date there has been no requirement to maintain Read codes in the LIMS at sites where the Roche SWISSLAB system is installed. Read codes are managed in systems external to the LIMS. Therefore, the release & transition to SNOMED CT does not impact Roche directly as LIMS supplier but does have an impact on our end users and their resource (which is at a premium given that we are in LIMS implementation phase). The transition to use NLMC and LOINC would require significant input and collaboration between LIMS suppliers, external system suppliers and end users. Though it may be possible, it is a massive undertaking to retrofit any existing LIMS implementation - it may only be viable to consider this move at new LIMS deployment? Any additional requirements to introduce coding into disciplines where it historically hasn't been required will only add to this undertaking and the challenges to be faced. 16. Bart’s Health currently use Cerner Millennium. We use SNOMED CT for diagnosis, problem and procedure listing using Cerner's implementation of SNOMED CT which does not support post co-ordination. The tools we do have are powerful for data extraction and using the descriptive logic in SNOMED CT. On the other hand our LIMS system is WinPath from Clinisys. This uses an unsupported version of SNOMED. The path for our organisation is first to ensure that all the labs in Barts Health use the same LIMS (we currently use 3 different versions of Winpath in 3 separate hospitals). Terminology use is one key to key reporting to GPs and within the hospital but we are constrained by our local resources, different LIMS platforms and vendor timescales.

6.5.1.7 Implementation 1. Very difficult to implement, this will be very time consuming with no extra money for extra staffing. Need to coordinate with GP systems as this has been a headache. 2. Cannot comment on the feasibility of the implementation until we see exactly what we need to do to implement this; Do we need to remap all our codes to SNOMED CT / LOINC or will there be some sort of conversion tool available to automate the process? 3. I do have an issue if there is a proposal to issue a SNOMED CT mapping set to be implemented and this is then followed by another migration to LOINC. 4. Whatever the final approach it needs to be unambiguous. Since LOINC and SNOMED-CT can be used for tests, results, samples etc. a final decision needs to

dictate which code is used for each entity. E.g. LOINC for Samples; SNOMED-CT for Tests or similar rather than allowing either to be used in a given case. 5. Also need to consider implementation rules as we have moved into era of electronic orders as well as results, which changes first, or should catalogue have two parts, orders (changed at pathology first), results (changed at GP end first) The complexities of each release will need to be understood, and will differ by configuration. Of concern is implementation on middle ware with no ability for me to check what "IT" staff are doing with inherent risk of wrong terms. Why is SNOMED release required? Are code lengths all the same, will there be mapping tables from one release to the next, and from baseline to "current" i.e. mapping tables from read to NLMC and SNOMED to NLMC? 6. To replace and test all of the READ codes for our 2,500+ tests would be a major project. Will there be funding for us to employ temporary support? 7. My main question would be how the adoption of these codes will affect the current messaging from Keystone. The MEDRPT NHS003 standard only supports Read codes or locally agreed free text descriptions. Will this message be redefined to also allow the transmission of SNOMED CT or LOINC codes, or will an entirely new pathology message be mandated? 8. Removing Read v2 from Keystone requires the following:  Removal of the code set type, and any implemented copies of this code set from the database.  Removal of the action and format settings that refer to the handling of Read codes, and the associated code.  Updating the validation and writing code to remove references to Read codes.  Adapting the current MEDRPT NHS003 would need the following elements:  Changes to the TD tables to make sure that they can accept the new code structures.  New code sets added to the database to store mappings from locally defined codes to the new standards.  Addition of new action and format settings to control the handling of codes.  Validation rule changes to support the inclusion of the new code sets.  Changes to the pathology message writing code to include the new code items.  Adding a new format would require similar changes to the above, except that all elements would have to be written in their entirety rather than adapting existing code. We have 85 Keystone sites so that is a lot of coding. 9. I have been contacted by many Trusts that are concerned that there is a general lack of clinical input - across suppliers we are concerned that there should be clinical input around terminology - otherwise the market is less likely to move.

7 Conclusion Given the timing of the consultation being conducted over the peak summer holiday period it was felt that a good response rate to the consultation was received. 7.1 Previews to releases The majority of response indicated they were interested in the development of pathology data standards by participating in National User forums or as subject matter experts.

The preference format for participation is by employment of technology using such as WebEx and telephone conferencing. This is not exclusive of holding face to face sessions such as workshops which will be necessary but limited format to utilise. 7.2 Release format The most popular release format requested is CSV (Spreadsheet). Other popular formats included XML and XSD which include a schema and a browsable HTML. A less populate request was for a Web subscription service. Though only a minority of respondents requested further information to accompany the release, those that did asked for such as;  The rationale for the changes being suggested and implemented. this will need to demonstrate a consensus has been reached following close working between the different system suppliers and system users.  Impact assessment of the changes should include clinical safety considerations.  Advice and guidance for conversion of units of measure for test results,  Linking the recommended units of measure with coding 7.3 Implementation Timescales A few respondents highlighted concerns around timescales, changes in coding standards which could result in confusion and implementation timescales. Others felt that early notification and opportunities for participation would be appreciated, and would assist the adoption and implementation. Further assessment is required to identify the impact of coding on suppliers of laboratory equipment and point of care testing equipment. End users resource and skill availability needs to be taken in to consideration for effective and successful implementation. Regular interactions between the different stakeholders are required. An open user group mentioned above will provide the opportunity for regular interaction together with the ability to email colleagues and participate in discussion groups. Due diligence is required before introducing coding standards. This will include considering amongst other things, the processes for submitting requests for new entries and authoring time scales, resource availability. Considering how the proposed coding systems are implemented and utilised in other countries, i.e. devolved nations and internationally is also required as part of due diligence processes. 7.3.1 Units of Measure The majority of respondents indicated implementation of changes in units of measure would take between 2-6 months. However, approximately 20% indicated that safe implementation of changes in units of measure would take 12 months or more. 7.3.2 Additions and Deprecations Although 59% of respondents indicated that they felt the timescale for safe implementation of additions and deprecations the deeper analysis revealed that for a ‘normal size’ release of recent times, deprecations would take generally longer to implement. However if that number of deprecations increased three fold the timescale for implementation was not relational.

8 Recommendations

We are encouraged by the response to this questionnaire and would welcome ongoing input from all interested parties. The Diagnostics Data team can be contacted by email [email protected] 8.1 Previews to releases Our analysis has identified that earlier engagement with suppliers, end users and professional bodies is necessary to provide sufficient notification and opportunities to discuss implications and undertake essential impact assessments as part of the change request process, which feeds into the governance process. ACTION: Implement open user group that convenes on a regular basis and is chaired by representatives of appropriate professional bodies. 8.2 Release format There needs to be one official release with options being available for computer consumption of other release formats. Provision of options should be made available by use of tooling to convert the official release into the desired format. ACTION: Confirm what tooling is available and what can be developed. Agree format of official release. Include in release packs reasoning for change and implementation guidance. 8.3 Implementation Timescales Sufficient timescale should be allowed for safe implementation of Units of Measure needs to be allocated in conjunction with System suppliers and End users. ACTION: HSCIC will work with lab instrument manufacturers, LIMS suppliers and regulators to plan a practical strategy for standardising units of measure across England going forward. 8.4 Terminology coding standard It is clear from the responses that the End users, System supplies, which must include LIMS, Middleware and GP system suppliers, and HSCIC must work together to develop the process for adoption and implementation.

ACTION: HSCIC Provider Support team to assist with early adoption by engaging with end users and working with them to provide an implementation plan and template. Develop experience and skilled resources in England where gaps for other coding systems e.g. LOINC exist. Single codes to be used need identified, clinically validated and technically ratified as part of the approval for use process. There should be a field within the NLMC that identifies tests according to the request environment, i.e. Tests that can be requested by a GP, Secondary care or lab ‘Reflex’ tests.

9 Appendix A – Questionnaire

Pathology Bounded Code List (PBCL) and PBCL Replacement.pdf 10 Appendix B - Organisations

 Aneurin Bevan University Health Board  Bart’s Health NHS Trust  Beckton Dickenson  Brighton & Sussex University Hospitals NHS Trust  Central Manchester University Hospitals NHS Foundation Trust  Chesterfield Royal Hospital NHS Foundation Trust  County Durham and Darlington NHS Foundation Trust  David Hamer Improvement Ltd  DGH  Doncaster and Bassetlaw Hospitals  East Sussex Healthcare  EMIS Group Plc  EMIS Health  EMIS National User Group  Epsom & St Helier University Hospitals NHS Trust  Gloucestershire Hospitals NHS F T  Haematology Lab, Antrim Area Hospital  Healthcare Information Consultancy Ltd  Herts Valleys CCG AND Harvey Group Practice AND EMIS National User Homerton University Hospital NHS Foundation Trust Group (NUG) Committee Member  Imperial College Healthcare NHS Trust  In Practice Systems Ltd  In Practice Systems Ltd  Integrated Software Solutions  InterSystems  Iuvo Limited  King George's Hosp / Lab Tests Online UK  King's College Hospital  Lancashire North CCG  Lancashire Teaching Hospitals NHS Trust  Leeds Teaching Hospitals NHS Trust  Lewisham and Greenwich NHS Trust  Maidstone & Tunbridge Wells NHS Trust  NHS England / NHSBT  NHS FIFE  NHS Gloucestershire CCG

 NHS Lothian University Hospital Division  NHS Wales Informatics Service  NHS-Walsall  NNUH hospital Trust  North Bristol NHS Trust  Northampton General Hospital NHS Trust  Papworth Hospital NHS Foundation Trust  RCPath  Regional Cancer Centre  Roche Diagnostics  Royal United Hospital NHS Foundation Trust  Sheffield Teaching Hospitals  South Devon Healthcare NHS Foundation Trust  Southampton  Southwest Pathology Services  St Helens & Knowsley Teaching Hospitals NHS Trust  Surrey University  SWBH Hospitals NHS Trust  The NHS  TPP  UK Renal Data Collaboration  University Hospitals of Morecambe Bay NHS Foundation Trust  Viapath  Vitalpulse Limited  West Hertfordshire Hospitals NHS Trust  West Kent CCG  Westside Medical Centre  Worcestershire Acute Hospitals NHS Trust  York Teaching Hospital NHS Foundation Trust

11 Appendix C – List of respondents roles

 Accountant  Biochemist IT  CCIO  Chair of edcomm  Clinical Biochemist  Clinical Scientist  Clinical Scientist with longstanding interest in electronic results interchange  Clinician  Consultant Advisor to Pathology Catalogues  Consultant Chemical Pathologist  Consultant Haematologist  Consultant Microbiologist  Diagnostic Healthcare provider to Pathology  Diagnostic Projects Manager NHS England  Diagnostic Systems Specialist

 GP  GP and CCIO for Gloucestershire CCG  GP & Pathology lead for CCG  GP IT system supplier  Head of Costing & Service Line Reporting  Healthcare IT consultant  Medical Informatician  Laboratory Director  Laboratory IT Manager  Laboratory Manager  Laboratory Order Communcations Analyst  LIMS supplier  LIMS supplier, Middleware supplier  Medical Informatician  Middleware supplier  National Pathology IT Programme Lead  Professional organisation, registry, quality improvement, patient access to health records via ‘PatientView’ , research, teaching, service to patients  Project Manager  Project manager in Pathology and Programme Manager for Lancashire North CCG  Quality Improvement Consultant  Renal Clinical software application  Scientist  Senior Biomedical Scientist  Trust IT Manager