Introduction of Systematized Nomenclature of Medicine–Clinical Terms Coding Into an Electronic Health Record and Evaluation of its Impact: Qualitative and Quantitative Study

Introduction

Background

The Digital Age has brought fast and convenient technology to almost all industries, and latterly to health care. The current system in Britain is divided between primary health care, where general practitioners increasingly manage chronic disease, and secondary and tertiary care, which largely remain modeled on hospitals. General practitioner records have been electronic for 20 years [1], but hospital records are only being ubiquitously considered for digital conversion now. These electronic health records (EHRs) are variable and often either overly simplistic [2] or require so much data input that they overburden clinicians [3]. EHRs have grown up separately and most still do not allow easy sharing of data, a situation further compounded by variability of the data themselves and lack of standardized coding [4]. Paucity of data exchange is not only a barrier to treating patients [5] but also prevents remodeling of medical pathways [6] locking the National Health Service (NHS) into artificial divisions between primary and secondary care. NHS Digital has issued guidance on the use of standards, including the universal use of the SNOMED-CT (Systematized Nomenclature of Medicine–Clinical Terms) for diagnoses [7] and other standards for medications, data messaging, and patient identification [8].

University Hospitals Birmingham (UHB) is a large secondary and tertiary referral NHS Foundation Trust comprising 4 hospitals and community services across Birmingham, the second largest city in the United Kingdom. UHB has an annual turnover of £1.4 (US $1.88) billion and treats 2.2 million people per year [9]. Across its 4 sites it has 3000 inpatient beds and employs more than 20,000 people. UHB has been at the forefront of digital innovation and is unique in the United Kingdom in employing programmers to build its own EHR. The organization was recognized as a global digital exemplar in 2017 [10]. It has strong links to primary care and is engaged in building regional data-sharing platforms [11]. Therefore, it is highly influential in digital health care development regionally and nationally in the United Kingdom.

The University Hospitals Birmingham NHS Foundation Trust’s (the Trust, hereafter) central EHR, named Prescribing Information and Communication System (PICS), [12] comprises contemporaneous clinical noting; electronic prescribing and medicines administration; electronic observations; electronic ordering; patient barcoding; and electronic results display and complex clinical decision support (CDS). UHB builds other software, including clinical and patient portals.

Electronic health care systems are ubiquitously used, and their design has been controlled by clinicians over many years. Diagnostic coding within PICS was based on the International Classification of Diseases, Tenth Revision (ICD-10) [13], which is the current system used for payment of hospitals. The ICD-10 was originally designed for population studies and is, therefore, not ideally suited to hospital settings. Clinicians often cannot find diagnoses they need because detailed or rare conditions are listed under any other.... Consequently, diagnoses are often not recorded and are therefore lost to use within any CDS rules and lost to data exchange beyond the organizational boundaries.

Implementation of SNOMED-CT coding into PICS was predicted to allow clinicians to more accurately enter detailed diagnoses, enable more complex CDS, and facilitate more accurate data collection, provided the tool was intuitive. In addition, there was a strong interest from the central government and the public to share health data. Primary care has already encoded diagnoses using SNOMED-CT, and similar data collection in hospitals would enable data exchange across previously incompatible data entry applications. This approach enables the remodeling of medical pathways and begins to address the siloed nature of medical care.

Objectives

The organization’s mission is to improve the health of patients and communities, and UHB is committed to transformation through consistent innovation across digital systems. The goals of UHB align with national expectations around standardized electronic data collection and the easy and seamless sharing of data [14]. In addition, clinicians require a more enriched and relevant system to record medical diagnoses. To address these goals, this study sought to establish coding within all components of the EHR based on the SNOMED-CT by April 2020. Therefore, the question was whether the current EHR, with all relevant patient data, could be migrated to the SNOMED-CT coding system, to optimize clinical use and CDS and facilitate data sharing across organizational boundaries for national programs and remodeling of medical pathways.

Methods

Overview

The formal methodology was designed to assess the success of the tool (utility or clinical relevance), success of mapping and safeguarding CDS rules in the software, and successful data collection for direct clinical care, research, and data exchange. This used pre-existing data sets, interviews, focus groups, and surveys of the stakeholders, and formal assessment of the use of the tool with quantitative data, using a mixed methods approach.

Existing Data Sets: Fixed Points

The design and build of the SNOMED-CT tool were created by clinicians and developers using an iterative model. Design meetings included clinicians, developers, business analysts, and a project manager, and a specification document was initially developed; development followed, and demonstrations of the software build and modifications were reviewed as they progressed over time. Many of the questions that the study explores in the postlaunch analysis (eg, “Is the tool useful?”) can be analyzed in this predata set, where the clinicians and developers worked together (eg, to create a tool that they believed would have clinical utility). The project specification document, specifically the user stories, provides a fixed point for analysis (Multimedia Appendix 1).

Surveys

A survey targeted at a large sample of clinicians after the launch of the SNOMED-CT tool assessed clinician opinion on utility and improvements in clinical care associated with the tool. The survey was sent by email across the Trust via Typeform [15] to all junior doctors and all consultants on the master staff index. Senior nurses (the only nursing group using the tool) were sent the same survey via the divisional leads; Allied Health Professionals (AHPs) were sampled using group leaders.

The SNOMED-CT tool was designed to collect consistent and standardized data, independent of which health care workers from the multidisciplinary team were collecting it. Thus, the tool had to work for doctors, nurses, and AHPs and be intuitive and accessible to junior and senior staff. To qualitatively assess whether this was successful, the study used a wide sample of users.

The sampling strategy was typical purposeful sampling, aiming to represent the average clinical situation and sample across all types of staff using the new tool. The sampling aimed to highlight the experience of this tool and understand the typical, normal, and average experience of a clinician using the tool [16].

Survey questions were developed with a focus on understanding staff experiences and future expectations regarding the use of a tool in constructing a problem list within a patient record. The tool’s utility in gathering data for direct clinical care, onward sharing, and the creation of research sets was explored. There were 7 elements to the survey (Multimedia Appendix 2) designed on a Likert scale [17] with one open-ended question, allowing for more detailed data collection.

From previous surveys of this type within the organization, the expected response rate was about 20%. The survey was designed for easy and rapid completion. Clinicians are busy, and traditionally ignore feedback requests. On the basis of previous experience and supported by market research [18], it was known that surveys exceeding 5 minutes would not be completed. The survey was therefore much shorter than a classical qualitative study survey, but accrued as much qualitative information as possible.

The validity and reliability of these items were tested by adequate engagement to saturation (the survey was repeatedly sent out to the staff lists until there were no new elements to answers) [19] and by triangulation or crystallization [20] of pre-existing data sets, focus groups, and data collection.

Interviews

Senior programmer interviews created an understanding of build success in relation to the original specification. Senior developers worked closely with clinicians and identified flaws in the design and implementation. Interviews with senior developers revealed difficulties and workarounds in the course of the build and illuminated reasons for subsequent clinician behavior. Interviews were designed as one-time sessions with each of the 2 principal developers in a meeting room in the building in which they worked. The interviews were informal and semistructured, asked open questions and allowed for follow-up and probing. The interviews were recorded and transcribed later, and notes were taken during the interviews. The questions (Multimedia Appendix 3) were designed to investigate, from the developers’ perspective, the success of the project, and the aspects that they viewed as strengths and weaknesses. Interviews also queried how developers viewed users and requested opinions about the implications of the project beyond the software build. The questions were deliberately open [16].

In similar previous projects, it was noted that developers who worked closely with clinicians often had insight into the software and possible enhancements that would improve user experience and data exchange. Developers are often reserved in their judgment and often do not proffer an opinion unless specifically asked.

Focus Groups and Email Feedback

Focus groups aimed to understand the validity and utility of the final product from clinicians involved in the iterative design and build of the software. In addition, unsolicited feedback from clinicians is a frequent part of the EHR build, and email feedback was therefore included in the thematic analysis. There were up to 50 clinicians involved in the design of the EHR, but the focus groups included between 5 and 10 participants, as this was an optimal number to support vibrant discussion while allowing all voices to be heard [21], thus using nonprobability unique sampling [19]. Clinicians who were invited were the ones most actively involved in the design and build, and to whom the tool was most relevant (because of direct clinical care, a research interest, or an interest in onward data sharing). Additional email feedback was not requested, but extensive feedback from this source was provided and was therefore included in the analysis. Clinicians in the focus groups and those who provided email feedback were likely to be a subset of those responding to the survey.

Two focus groups were conducted with 6 and 8 clinicians. The focus groups were informal and semistructured with prompts (Figure 1), which not only allowed for expression of opinion on the entire conceptual framework but also allowed for discussion, so that aspects of the project that had not been previously understood by the investigators were revealed.

The questions were designed to understand the utility of the tool in terms of clinical use and acceptability. This requires careful assessment, as clinicians may welcome even clunky digital tools if they think that patient care is improved. In relation to the conceptual framework, questions on the applicability of the tool to direct clinical care, research, and data sharing were also explored.

‎View this figure

Data Analysis

Pre-existing Data Sets or Fixed Points

These predated the study and were analyzed by extracting data against the key themes of improving care, improving access to data, and ensuring usability of the tool. The data set comprised user stories from a specification document developed iteratively with developers and clinicians. Suggestions and actions incorporated during the data build were analyzed and used to understand whether the same points were discussed in the survey responses and focus groups (eg, were they addressed in the build? If they were not, why not?). The documents were coded in a similar manner to that of the focus groups, which allowed theming and issue spotting.

Surveys

Descriptive statistical analyses were conducted on the results after all the surveys were submitted. For all questions answered on a Likert scale, responses to each question were analyzed as whole numbers in each group. Binary questions were presented as percentages. The analysis of open questions gathered themes with the quoted examples.

Interviews, Focus Groups, and Email Feedback

Interviews and focus groups were recorded and transcribed, and thoughts, concerns, and conclusions documented by the investigator during or immediately after the interviews or focus groups. The transcription was coded and scored on a matrix (Figure 1) for frequency, concern, and time spent discussing each issue and where they overlapped using a multifactorial balancing test-like methodology [22]. Themes or issues were identified and cross-referenced with survey results and pre-existing data sets.

Informal email feedback was collected by the chief investigator and incorporated into the thematic analysis.

Use Data

Data were collected digitally on the use of the SNOMED-CT tool across the entire organization by the Informatics Department. The following data were collected: total number of users, by area and specialty; number of terms used, by user and by specialty; and application over time (for the first 4 months of use) to understand whether the use was increasing or waning. These data were presented graphically as absolute numbers and as the percentage use of the total user base.

Ethics

Human subjects were involved in this research, and participation was voluntary and confidential. Informed consent was obtained from all participants, including for recording and storing of information, and consent could be withdrawn at any time until results were collated in an anonymized manner. Any quotations from the interviews and focus groups were only used with consent. It is unlikely in a study of this type that interviews or focus groups would cause ethical issues to be raised as private behavior was not the subject of this study [16]. The data were stored securely and confidentially.

Bias arising from the dual role of the researcher as a designer or user and evaluator of the tool [16] was mitigated by processes already in place. All software build within the organization was controlled by a project group, with a project manager, business analyst, standard testing, and rollout procedures. Although researchers have invested in the project, many software developments to date have required extensive iterations to ensure utility, and this was expected to be necessary in this project also.

Results

Overview

Data collection took place during September 2019-December 2019 and was conducted at UHB, United Kingdom. Statistics for the problem list in PICS were gathered by the Informatics Department, from the date of the tool release into PICS software, September 2019, to the end of December 2019.

The 5 key themes with subthemes that emerged from this study are detailed in Table 1.

Questionnaires were sent to 585 junior doctors, 315 consultants, 40 senior nurses, and 20 AHPs. In total, 15.3% (147/960) responded to the survey. The survey was anonymous; thus, the role of the respondents was not recorded.

Design, Commitment, and Project Success

The project delivered the planned tool. The requirement for programmer time was high, up to 40 hours per week in the last month of the project, with extensive preceding groundwork for the project team. A total of 300,000 new codes were added to the EHR, and 15,000 old codes were mapped to new codes. Because of the considerably increased detail in SNOMED-CT compared with the ICD-10, this mapping was complicated and multiple SNOMED-CT codes had to be mapped back to each ICD-10 code. In addition to coding, the existing EHR had over 1000 existing CDS rules, all of which were successfully mapped to new codes. All these changes required a new user interface (UI), which was iteratively built with clinicians.

The programmers who built the new tool felt that the overall project was well organized and well managed. However, programmers were frustrated at the time required for mapping and checking the codes. The programmers felt that coders should have been involved earlier and more extensively. Before the project, the programmers were concerned that loading thousands of new codes would slow down the application, reducing both the speed of the search and the EHR application itself. This concern did not materialize because search speeds and EHR stability were not impacted by the loading of a large number of new codes.

Programmers further commented that predicting problems in organizing and anticipating questions was difficult in innovation projects of this scope. Fixed data sources (Multimedia Appendix 1) included specification documents and these outlined user stories identifying what users articulated as their need. All phase 1 requirements were delivered. Some modifications were requested in the feedback, which are outlined in the themes below. Similar to the programmers, users fed back that the project was successful. Users had assumed that it would be successful, as the build of EHR in our organization has a good track record for the delivery of successful tools.

Usability

This tool has been widely used. After the first month, codes entered into the EHR rapidly rose to between 6000 and 7000 a month and continued to be high over the 4 months of the study (Figure 2). This was higher than expected, as no specific communications or advertising was put out to the organization. The expectation is that the number of codes entered each month will fall as more returning patients have most of their medical history added to the EHR. It is anticipated that a steady state will be reached in approximately 12 months with only new patients or new problems being added to the system.

Codes were used in all specialties. As expected, the highest use was in general medicine, short-stay ambulatory care, and critical care, but use was seen across all hospital specialties (Figure 2). Most users were doctors and a significant minority nurses. Small numbers of pharmacists and AHPs were starting to use the tool during the study period, and this is expected to rise as these groups of professionals generally follow doctors’ behavior.

‎View this figure

Most study participants thought the tool was easy to find (Figure 3) and that diagnoses could be searched for effectively. Most participants also thought that the new problem list was displayed in the right places in the EHR. There were several examples of user feedback requesting changes to the UI; dates did not appear until final commitment to the record that confused some users, and users suggested the addition of abbreviations in the search box.

Most of the required diagnoses seemed to be available, although ophthalmology was reported to be sparse, and some specific diagnoses were not found. Some doctors asked how to add diagnoses to the SNOMED-CT itself. Overall, however, users more frequently commented that there were too many diagnoses rather than too few, and they did not understand that synonyms mapped back to the same codes (Textbox 1).

More fundamentally, surgeons commented that end dates did not make sense for operations. They felt that even though the problem had ended, surgical history should persist on diagnostic lists. Specific dates for some diagnoses were also thought to be irrelevant. Textbox 1 below is a compilation of free text data from the combined methodology, detailing respondents’ perspectives around the core areas of utility, diagnosis search, and dating diagnoses.

‎View this figure

Engagement

The issue of clinicians not entering all relevant diagnoses was raised many times, but as these are persistent data, users thought these may accumulate over time. Doctors felt motivated to enter data but were restricted by time constraints and demotivated by the perception that other doctors and other staff members were not doing a share of the work. Nurses, patients, and coders were all expected to be potentially powerful contributors to the problem list. Finally, education was raised as important in user engagement.

Data Quality

Users expressed that the data needed to be correct and updated. Ensuring that all users entered correct and complete lists was thought to be potentially problematic, and deletion of irrelevant or incorrect items from the lists was raised as a concern. Typical feedback about the quality of data entry and barriers to the affective gathering of data are illustrated in Textbox 2.

Improving Patient Care

In the questionnaire, users were ambivalent about the tool positively impacting patient care (Figure 3). However, in focus groups, clinicians thought that the problem list positively contributed to patient care and could have wide implications for safety rules. It was also recognized as improving communication.

There were concerns about lists becoming too long and that loss of human sorting of lists could lead to a loss of nuance. Many doctors use clinical letters to present a list of patient problems, which are subtly changed in each specialty with a different ordering or grouping of problems. Doctors may also exclude problems that are less relevant to their specialty or add details that are not understood (or transcribed) by other specialists. Building relevant patient lists that cater for all is probably the most challenging aspect of building relevant electronic lists. The current situation in which some information is missed or excluded by doctors may be dangerous, but an alternative that overloads clinicians with information is also not ideal. Pragmatic solutions, where “one size fits all,” will require extensive clinician collaborations and consensus. Detailed feedback from the various methodologies that exemplify these points is presented in Textbox 3.

Use in Research or Audit

The principal concern regarding the use of codes for research was the overlapping of codes and lack of granularity. However, users also noted that the tool was already being used in audits. Many clinicians have recognized the potential for research and expected that digital development could contribute extensively.

Use in Data Sharing

In the questionnaire, users generally thought that the tool would improve data exchange (Figure 3). It was generally agreed that more standard and detailed coding made data sharing easier and that this was desirable for patient care. Users were interested in sharing the data with general practitioners and other hospitals. Clinicians were also interested in the idea that data could be pulled into the hospital system for acute and outpatient care. User feedback is presented in Textbox 4. Of note is that users remained concerned about the number of codes available, although there is some recognition that these can be mapped to each other or grouped for the purposes of research and clinical care.

Standards and Payment

Data sharing was also discussed in relation to payments and uploads to national registries. Programmers were the only group that discussed the NHS standards (Textbox 4).

The Importance of Various Themes to Users

To understand which aspects of the tool were most important to users, feedback from the focus groups, interviews, emails, and free comment text in the questionnaires were marked to understand where comments or conversation had been based on particular themes, and analyzed for time spent (Figure 1). In the focus groups and interviews, this was measured as the actual time spent in discussing an item; in the questionnaire, and email feedback, this was the length of free text comments written by respondents.

Overall, users were most concerned about the ease of use of the tool and its direct use. They were then equally concerned with patient care, data sharing, and further development. All users talked about all the themes except for programmers who, as expected, did not talk about usefulness, as they were not users. Questionnaire comments focused on how easy it was to use the tool, with some focus on usefulness and patient care.

Interestingly, the 2 focus groups spent time on different themes, despite having been shown the same facilitation tools. One group discussed data sharing extensively and the other future developments. Neither focus group discussed patient care in depth, which may be because of the seniority of the doctors in these groups, for whom the importance of good patient care is already assumed to be high.

Validity and Reliability of Data

Data were triangulated from fixed-point data sets, surveys, interviews, and focus groups with the data collected on actual use statistics. Survey data were collected until saturation or redundancy was reached. To reduce nonresponder bias, the survey was constructed carefully using proven techniques to ensure experience, opinion, and emotional response without deploying leading questions or resulting in dead-end answers [16]. Reminders were deployed to increase response rates, and the survey was deliberately short so that it was easy to complete. The survey was digital to ensure the ease of returning completed responses. The principal investigator has a relationship with many clinicians across the organization, and this was exploited to increase response rates. Member checks ensured internal validity by soliciting feedback on preliminary findings from participants to check the correct interpretation [23].

Discussion

Principal Findings

This study demonstrates the successful conversion of a hospital electronic record to SNOMED-CT with high clinician acceptability, which forms the basis of data sharing, innovative use of data, and availability of coded clinical information for research.

SNOMED-CT as an ontology has been developed over several decades [24] and represents a detailed and multifaceted database that can be used to accurately describe patients’ conditions, medical and surgical history, and current problems. The ontology is divided into several levels, allowing both specific detail and broader general categories, and these are linked together in a web structure [7].

There are several coding structures currently in use in the English NHS, including the ICD-10 and Office of Population Censuses and Surveys Version 4, which are the current methods of payment for hospitals [13,25]. In general, these methods do not provide the depth or detail required to describe patient conditions. This lack of detail leads clinicians to look for better ways to encode clinical information [26-28].

Data Exchange

Clinicians and patients increasingly demand safe exchange of clinical data to optimize clinical care [29]. This can be leveraged in secondary data collection for research to safeguard future population health [30]. The interoperability of health systems, and in particular, moving data between systems, has been discussed extensively but has not been realized to date [4]. One of the major hurdles is nonstandard data collection [31]. It is difficult to transfer data where mapping from one coding system to another is needed, especially when the mapping is from one generalized diagnosis to many more detailed ones. In an ideal situation, the primary data sources would collect data in a single standard coding structure, facilitating easy data exchange [14]. Clinicians in our study recognized the need for data exchange and welcomed a tool that actively facilitates sharing.

The national strategy in England is clearly set out by NHS Digital with aspirations for all aspects of the English NHS to use SNOMED-CT from 2020. Conversion is under way in primary care and secondary care, acute care, mental health, community systems, dentistry and other systems used in direct patient care must use SNOMED-CT as the clinical terminology, before April 1, 2020 [7]. The conversion of commercial systems has been slow [32], but continues to increase.

Previous Transitions

There are no published examples of SNOMED-CT conversion in a complex hospital EHR that supports CDS, but there are several case studies of smaller successful and unsuccessful implementations of SNOMED-CT in EHRs. Lee et al [33] studied 13 implementations, 5 of which were hospital-wide, and 4 of these involved diagnostic lists. Clinicians found that SNOMED-CT did not always include all diagnoses that they required. In a small Portuguese study [34], user acceptance was high, and the adoption of SNOMED-CT enabled system interoperability. More recently, in Wales, the successful development of a neurology database using SNOMED-CT has influenced direct patient care, allowing accurate web-based reporting and informing clinical research [35].

Currently, there is very little published literature and there are no peer-reviewed papers describing the impact of primary or whole system secondary care transition to SNOMED-CT in England. Many of these implementations also reported benefits not directly related to SNOMED-CT, but rather to transition from paper to digital recording [33]. The principal trends from previous implementations were reflected in our study—the hierarchy was challenging to use, some concepts were ambiguous, and there was some syntactic inconsistency. The combining of multiple terms used in SNOMED-CT was also challenging and consequently created difficulties in data retrieval [33-35]. Success trends could also be found; implementations were successful as the UI was simple and immediate value was demonstrated to clinicians. Synonyms allowed clinicians to easily find terms and reuse the data.

Interface

Clinicians not only require a coding system that encompasses all the diagnoses and procedures that affect patients; they also want a seamless UI for data entry [33]. By providing a more complex and detailed coding structure, an unintended consequence may be that the data entry application is so complicated that clinicians disengage, resulting in a paradoxical decrease in acquired data [36,37]. The SNOMED-CT database is complex and needs to be presented in a way that makes sense to clinicians [38,39]. The interface must be intuitive and not overwhelming, and the search engine must return specific terms in a helpful order [40]. Data exchange must be considered at inception [4], and mapping back to other coding structures must be possible, for example, to national data sets for reporting [41] and to the ICD-10 for payment [42]. Of note, where enriched data are collected by clinicians, mapping back to the ICD-10 for payment can be effective in increasing hospital income [43]. Reflecting these points, we found in our study that clinicians accepted the use of SNOMED-CT, but care was needed in the presentation and utility of this vast database in clinical EHR. In general, clinicians report success in using the tool, finding the depth of the coding useful and applicable [33]. Clinicians, particularly doctors, are in general interested primarily in providing excellent patient care, and drivers for successful projects are therefore efficient patient safety [26,44] and research for population health [45].

The organization has a long history of user-led design, and the strength of the EHR is that it is “designed for clinicians by clinicians.” Increasingly successful digital health systems are reported to have a human-based design at their core [4,46-48]. Bringing developers and users together is reported to increase usability and value [49,50], forming the basis of user-based co-design [51].

Embedded in Complex EHR With CDS

In addition to the literature on SNOMED-CT and its implementation, the design of the EHR is crucial to the success of the project. Independent of the coding structure behind it, the EHR must be highly usable to engage clinicians, and must be intuitive and helpful or risks disengagement [3]. Data sharing for direct health care, or for population research to safeguard future generations, is only possible if data are entered into the record in the first place. Therefore, interface design is crucial [40,46], more so in implementations involving extremely complex coding systems such as SNOMED-CT. In addition to design, standards that are universally adopted (or enforced) are required to allow data sharing and interoperability of systems to work [5,8,52]. Sophisticated CDS or artificial intelligence algorithms cannot be leveraged if clinical records are devoid of data.

Beyond the transition of EHR to SNOMED-CT, there is limited literature on its subsequent use in CDS and artificial intelligence. Previous studies in this area have briefly discussed the use of SNOMED-CT in CDS [53,54], but have not explored the complex mapping that is needed to link existing rules to multiple codes as a result of the one-to-many mapping. SNOMED-CT has the potential to greatly enrich medical records [34] and therefore enhance the safety and quality of care via CDS [53]. The detailed diagnostic codes in SNOMED-CT may also allow the development of more precise CDS in the future. The extensive work needed to map all the codes in an existing system was completed, although it took time.

In addition, the transition of complex EHR to SNOMED-CT must consider some unique problems. SNOMED-CT is compositional, negating the need for a large number of specific terms. Therefore “left pneumothorax as a complication of a chest drain” does not exist in SNOMED-CT; terms must be combined to reach concepts that are applicable to patients. Compositional systems allow greater reuse of data without the need for human intervention for the interpretation of the categories [55]. The challenge is to allow clinicians to choose from the richness of the database, including combining of concepts, while safeguarding the CDS rules so that any concept related to the conditions in the rule is fired by all of the relevant SNOMED-CT codes that clinicians choose.

Health Ecosystem

This project took place in a large secondary and tertiary care hospital ecosystem consisting of 4 hospitals and community services. This ecosystem has nascent links to primary care records via a project that does not yet exchange data but uses a “look up and leave” data sharing platform [56]. Beyond the institution itself, the EHR has been acquired by 2 other hospitals in the West Midlands [57,58]. Similar ecosystems in the United Kingdom are now increasingly implementing EHR [59,60], and in North America, many have already done so [61]. There are limited examples of acute care ecosystems that implement a change in coding, but a few exist [34,62]. None of these studies, however, achieved recoding in a complex EHR that supported complex CDS rules, and none of these examples reported on data exchange after the coding change.

Of note, although this study is restricted to the acute hospital setting, the whole of the NHS is influenced by projects of this kind. By converting coding central to one of the largest acute trusts in the country whose influence through its software extends beyond the institution itself, this project contributes to the facilitation of national data exchange.

Limitations and Delimitations

The limitations of this study are largely related to the time-limited nature of the study; thus, a pragmatic approach had to be taken for the number of respondents for the survey and the number of focus groups that could be undertaken. The study protocols aimed to continue the survey until saturation was reached and to reduce bias from nonresponders. However, this was not entirely possible, and the study therefore needed to focus on deep analysis of smaller data sets rather than unrealistic expectations of analyzing extensive data sets.

Limitations beyond the control of the investigator were the truthfulness of the responders, the attendance of participants to invited groups, and consent for research inclusion.

The research was only able to study the response to the new tool for the first 4 months after its launch. This may not have been representative, as novel software may be used extensively initially with a reduction in use over time, or conversely, may increase as more clinicians become committed to data sharing. Pre-existing data sets were brief notes, capturing requirements for software build and modification. Although imperfect, these were valuable resources for comparing the attitudes and requirements of both stakeholders before and after the launch of the tool. Finally, the study could not study the repetitive loops of development, and it is likely that iterative changes to the tool are needed.

Lessons Learned

The following lessons were learned during the development and implementation process:

1. Clinicians will accept the task of adding SNOMED-CT–coded diagnoses into an electronic record provided the UI is intuitive, but they will disengage if the process is too complex.
2. The underlying EHR must be highly usable to engage clinicians.
3. Bringing developers and users together increases usability and value by engaging in user-based co-design.
4. Clinicians are driven by patient safety, data exchange across the health system, and research for population health.
5. Sophisticated and CDS or artificial intelligence algorithms cannot be leveraged without this data collection.

Conclusions

This study demonstrates the successful conversion of a hospital electronic record to the updated standardized coding of diagnoses, with high clinician acceptability. The project began with clinician demand, followed by the building of a clinically led tool and extensive examination of its success and requirement for iteration. Starting in one institution, this has implications for the entire NHS. This tool is important because it supports national aspirations for enhancing patient care through CDS and allows for data sharing, innovation, and research. The project is a blueprint for capturing the data that form the bedrock for driving artificial intelligence and full digitalization of health care, and it is therefore a benchmark for transformation and innovation, influencing the aspiration to safeguard health for future generations.