Design

We undertook a qualitative case study.9 The ‘case’ was the documenting in England of diabetes health care provision in patients’ records, that is if and how information on these patients is being digitally captured and transmitted. An in-depth case study allows the description of any currently used technologies (hardware and software) and work practices, with a focus on how and why different forms of data capture – free-text, narrative, structured data (e.g. using a template) and coded data (e.g. with Read Codes) – are being used in these health records. The case study design also allows a detailed exploration of a range of views on the optimal balance between unstructured, structured- uncoded and structured-coded data recording, particularly for clinical care but also for NHS management, diabetic service planning, research and audit. We sought to illuminate how the ways in which data were documented facilitated the management of the long-term condition, for example through call and recall prompts, health status monitoring and supporting communication between health care professionals.

Sampling

Two primary care sites and an NHS hospital in the same region in England were identified as possible case study participants through the UK Clinical Research Network.10 Choosing associated family practice and hospital sites was designed to give a coherent picture of a geographical health community, in which the majority of patients diagnosed with diabetes receive care. It also allowed us to generate contextspecific findings from the sites as well more generic findings that were likely to be generalisable from considering the sampled sites together as a holistic ‘case’.

We used purposive sampling11 within the sites and beyond them to identify and recruit a wide range of individuals who affect or are affected by the processes and outcomes of documenting diabetes patients’ health care. Interviewees outside the sites were selected to provide contextual information for the case study and to provide additional perspectives. Throughout, we actively sought to sample a range of experiences and views, including outlier views. Interviewees included clinical staff (doctors, nurses and allied health professionals); patients; NHS managers; clinical coders; clinical systems developers/suppliers and academics.

Data collection

Initially, we purposively recruited and interviewed eight individuals in England and Scotland with a particular interest in diabetes and structuring and/or coding of health records in order to gain their perspectives as academics (including academic clinicians) and health care informatics experts (including developers of HIT systems). This was achieved through research team contacts and snowballing, whereby one informant suggests another informant. These early interviews allowed the subsequent interviews in the case study sites to be conducted in the context of information about the situation more widely in the UK and beyond. Interviews were guided by initial topic guide schedules derived from the research protocol, which were adapted by the case study’s lead researcher as the investigation progressed. Audio files of recorded interviews were transcribed professionally. Additional data were collected in field notes taken during two non-participant observations in a family practice diabetes review clinic and naturalistic, on-site observations in hospital. Although this study did not aim to assess the technologies, demonstrations of some HIT systems commonly used for diabetes management in the UK provided further background information. We also reviewed relevant documentary data, including diabetes-related websites, documentation on different coding systems and current local and national diabetesrelated guidelines and protocols, as background information before undertaking the case study interviews and observations.

Data analysis

Thematic data analysis12 and data collection were iterative, allowing identified themes to be further explored and any discrepancies between individuals’ accounts or between data sources to be further investigated. Interview transcripts and field notes were uploaded into the qualitative software package NVivo 8.13 For the thematic analysis, coding was guided by an initial framework of categories derived from the research protocol, a literature search and research team discussions. These categories were refined as the interview data collection progressed. Coding combined top-down coding, based on the coding framework, and bottom-up coding in which new or more fine-grained themes emerge out of the data.14 Interpretation of the findings was influenced by a socio-technical theoretical understanding, i.e. that technologies and those who work with them function inter-dependently.15 Approaches to validating data quality and credibility in this qualitative case study included checking data for face validity, looking for disconfirming evidence, data triangulation by data source and discussing data collection and analysis in the wider team throughout the research process.14,16

Ethical considerations

We obtained Research Ethics Committee approval and local site permissions. Interviewees gave informed consent before being recruited, and all data were anonymised to protect participant confidentiality.

Working in different worlds

Our case study illustrated a marked contrast between the sampled sites. In a busy NHS teaching hospital, diabetes patients admitted into hospital wards were typically very unwell, for example with kidney or heart failure, or they were maternity patients. The hospital consultants and their teams looked after hospital inpatients. Hospital consultants also saw diabetes patients in community clinics. Here, they worked in collaboration with community nurses, although not with family practice doctors. Hospital doctors relied on paper to record information about diabetes patients. The hospital had implemented a number of different HIT systems, such as a pathology system, but had no comprehensive EHR system.

‘There are plans to introduce EHRs in the future. The hospital X-ray system is different from the system for blood results, which is different from the patient management system. At the moment, I have to log into about at least five different systems to get information on a patient. So I created my own diabetes template. Yes, it’s a paper template and I use it for my patients, and a couple of other consultants have been using it for their clinics too’. (Hospital Consultant)

In contrast, the context in which family practice staff worked was a self-contained, computerised surgery, where the use of HIT systems and coding were well established.

‘We’ve got a good system in place. We’ve been doing it a long time here. We code everything. Whoever is entering it does a Read Code’. (Family Practice Doctor)

There were four types of data capture using the family practice HIT system’s diabetes template: numerical values (e.g. weight and height); yes/no options (e.g. smoking); dropdown menus (e.g. diagnosis) and free text boxes (e.g. for comments on dietary advice that had been given). In addition, information about diabetes patients and their care was recorded in free text in a separate part of the EHR, which was also coded. There was minimal free text that was unrelated to an entered code. For example, a family doctor described coding all her entries in a patient’s record with the exception of a free text comment on her reasons for altering the patient’s management plan. Unlike in the hospital setting, where the paper template meant handwritten entries were structured but there was no coding in the record, the family practice record entries were predominantly coded.

Communicating across the divide?

The family practice was the main health care setting in which the majority of diabetes patients received most of their care. Nonetheless, some patients would be referred to community clinics to be seen there by hospital consultants, and there were some patients who had episodes of inpatient hospital care. NHS staff interviewees from each sector described largely working in isolation from the other. Letters were the most common method of communicating information between the hospital and family doctors. Phone and fax messages might be used instead of paper if the message was more urgent. Digital data sharing across the care boundary was restricted to some laboratory results, which would then be coded in the family practice HIT system.

‘Everyone functions sort of independently. We get each other’s letters. Most letters are probably accurate, but it’s not in real time’. (Hospital Doctor) From a system supplier’s perspective, the difficulties of modernising communications between family practices and hospitals with HIT systems were less technical than political and economic.

‘We can put what you like in the can, but there are very few good examples of good integration between primary and secondary [hospital] care in England. The reason is partly from a lack of will – there is demand, lots – but no-one is picking up that ball. How to fund it? Also, there are some issues around information governance and so on. GPs [family doctors] are cautious about who sees their data and so on. The majority of processes are not integrated across primary and secondary care at all’. (Systems Supplier)

A hospital doctor described dictating his letters to the family practice in front of the patient, and a copy of the letter being returned to him for review and signing after it had been transcribed by a secretary, then the letter being posted. This process took several days, with hospital test results often following later. Electronic document transfer would be a relatively straightforward step that would reduce some delays in passing patient information from one sector to the other and allow patients’ records to be updated in a timely manner:

‘For communications, it’s normally in the form of a letter, and there are tools for configuring and producing letters, and it’s possible to convert to electronic document sharing at some sites - but integration – that’s the next leap’. (Systems Supplier)

Elsewhere in the UK, the integration gap for diabetes patients was being addressed through HIT. In Scotland, a national, computerised system, now called SCI-Diabetes, still widely known as SCI-DC,17 combined information from a number of sources, including from podiatrists, dieticians, hospitals and the family doctor, to give diabetes patients a single, quickly updated record.

This clinical system had taken some 10 years of investment to collect the data and set up the systems, building out from a smaller regional system. Interviewees in Scotland said the development of SCI-DC had benefitted from the drive and enthusiasm of particular individuals who had been its ‘ champions’ but they were unanimous in reporting that the long effort had been sustained by the interest and support of the clinical community more widely.

‘The approach was always to work with those who wanted to sign up to the system and let the uninterested or refusers see the benefits over time and join in later. Now nearly all GPs [family doctors] and all hospitals are signed up… It’s about integrating the whole thing into work patterns, and also about the rewards for clinicians, such as having blood results available for the consultation, not having to dictate results anymore and having an organised letter. Scotland has gone a wee bit independent, and is doing very well’. (Hospital Doctor/Academic)

Drivers for structuring/coding diabetes information

The sampled sites shared a financial incentive to code diabetes data. For the hospital, it was income derived from reporting activity under the payments by results (PbR) scheme. PbR payments accounted for a significant proportion of the hospital’s overall income. All participants at the sampled hospital site reported they were conscious of the financial difficulties facing the NHS during a period in which employees’ posts were being reviewed and the clinical workforce was being pared back. However, not all made the link between coding, PbR payments and the hospital’s finances.

‘I don’t think I ever thought about it until I started research work. You go all through your training and so on, and coding and its importance is never mentioned, or if it is, nobody takes it in. It’s just something that goes on behind the scenes. You don’t even know where the hospital coders are’. (Hospital Research Nurse)

Similarly, family practice interviewees mentioned paymentrelated quality outcomes framework (QOF) points as being one driver for coding.

‘It makes sense if everything is coded correctly because it is income for the practice’. (Family Doctor)

In addition to the financial driver, family practice staff referred to a ‘culture’ of using computers and coding in doctors’ surgeries, where computer systems had been in use for years. Clinical and non-clinical family practice staff recognised the need for coding in order to be able to carry out searches and audits as part of their everyday work. They were also motivated to code because having coded information was perceived to improve direct patient care.

‘Codes mean you can search and identify patients, say, who need six monthly blood pressure checks or who have not turned up for a B12 injection. It does improve patient care’. (Family Practice Coder)

Improving patient care was also given as the reason for structuring patient information using the hospital consultant’s paper templates. Paper templates were a pragmatic solution to encourage standardised, clinical practice and to aid the completeness of recording patient information in the absence of hospital EHRs and digital templates.

‘In an ideal world, yes, I would like a diabetes HIT system but in real life, if I aim for it, it won’t happen because of finance. So I just got on with this. From the first day someone hits my ward, they get a yellow sheet and all the co-morbidities, medications, interventions are there, and we update the yellow sheet on a regular basis. It forms the basis of the discharge letter. Simple things, like pre-conception counselling – it is very easy to miss it otherwise’. (Hospital Consultant)

Who codes and how?

We observed marked differences between settings with respect to who did the coding and how this was done. Read codes were used in family practice. This is an extensive list of terms, each attached to a unique code and which covers information ranging from the patient’s occupation to signs and symptoms, tests, diagnoses, interventions to medications and more. In the family practice surgeries, it was predominantly diabetes specialist nurses who completed digital diabetes templates during, or sometimes shortly after, diabetes review appointments. Read coding was embedded in the digital template. The family doctors were more likely to use another part of the EHR for their consultations with patients with diabetes, and to code those entries themselves. Another staff member also had a specific coding role, whether the job title was ‘coder’, ‘clerk’ or ‘secretary’. This individual would complete data entry and coding in the EHR when information about a patient arrived from the local hospital.

‘Filling in the template automatically fires codes behind the scenes. It is embedded in the system. We always code for type 1 or type 2 diabetes. I would say nine out of ten templates are fully completed. Obviously, some of it can’t be done during the review appointment, for example when someone has an eye check at the opticians, obviously we don’t do that here, but when the paperwork comes through from the optician, or the hospital letters with, say, blood pressure results, I put it on the patient’s template. All letters normally get sorted within a couple of weeks. If there was anything urgent, they would fax, but normally it’s routine results by letter and they get updated and coded in the patient’s record within a couple of weeks’. (Family Practice Coder)

In the hospital, coders used International Classification of Disease (ICD-10) codes for diagnoses and Office of Population, Censuses and Surveys Classification of Surgical Operations and Procedures (OPCS-4) codes. Coding was based on the content of patients’ discharge summaries which were sent to a team of professionally trained, full-time coders. We observed the coding team accommodated in one large room in the hospital, where the coders worked from their own copies of coding manuals that were extensively annotated and individualised with comments, reminders and coding updates. They dealt with coding queries arising from information that was unclear, inconsistent or missing from the discharge sheet by telephoning the doctor who had written it. An interviewee described how they were tightly constrained by the content and completeness of the discharge summaries that doctors produced. There were variations between hospital departments and between individual doctors, which professional coders came to recognise:

‘We have one doctor who doesn’t like calling people ‘geriatrics’ so she won’t put down a geriatric fall, she will put down a mechanical fall, but there is no code for mechanical fall – so we have to phone her up. And it could be that the person fell and broke their leg because they were hypo and really it was diabetes that caused the fall but that won’t be what’s on the discharge summary, it’ll be surgery for a broken leg, so that’s what’s coded’. (Hospital Coder)

Coding based on discharge summaries, rather than the whole record, had implications beyond missing diagnoses codes. Interviewees discussed how some activities also became ‘invisible’. For example, a dietician would spend time on a non-diabetes ward giving dietary advice to a patient with diabetes, but it would be the activities relating to the primary reason for patient’s admission – not diabetes – that would feature on the discharge summary and hence get coded.

In some instances, a coder might work in a clinical department and code directly from the patient’s hospital record. This depended in part on the availability of accommodation for the coder in the department and on the coding interest of key individuals in that speciality. A coding manager reported this was time consuming but resulted in more complete and accurate coding. The hospital’s coding department was being relocated and losing a number of desks, which meant that in future coders would be more likely to do at least some of their work from home.

‘Coding from the patient’s record has real advantages over coding from discharge summaries. That would be the ideal. A big part of what we are trying to do now is to get out there, for coders to meet clinicians, so at least they remember a face, and they understand what we are doing and why it is important. But we are juggling with other considerations too, like fewer desks for us in the new hospital’. (Hospital Coder)

Another participant described noticing misclassification of diabetes type in the course of research work she had conducted at the hospital, based on her own specialist knowledge of the disease.

‘I could see type 1 and knew it was not but it got put on because of insulin and once it was coded that way…’ (Hospital Research Nurse)

Similarly, a family doctor remarked on the problem of miscoding of type 1 and type 2 diabetes in the family practice HIT system, particularly from coding in the past:

‘The only problem is where someone is coded as insulin dependent, and is it truly type 1 or type 2? Some of the old codes in the system need a bit of tidying up’. (Family Doctor)

In Scotland, the coding approach for the national research register derived from the SCI-DC system17 included inferring diagnoses of diabetes. Recognising that statistics from any one source were unreliable, such as a diagnosis of diabetes being missed from a hospital discharge summary, SCI-DC was designed to reconcile diabetes data from multiple sources, including laboratory data, the retinopathy screening programme, podiatry and data from both secondary and primary care, in order to improve the quality of the aggregated dataset.

‘We would like all diabetes diagnoses and check-ups to be properly coded but this is not done. We are conservative in making any inferences, we err on the side of caution. For example a blood sugar check, no, but if a GP had coded for a diabetes clinic check-up, although they have not coded a diagnosis of diabetes, yes, we could infer a diagnosis of diabetes’. (Clinician, NHS National Services Scotland)

Involving the patients

Family practice nurses were observed using the HIT system to generate graphs on screen to illustrate trends for that individual in such measures as weight and glucose control. The graphic illustration was accompanied by the nurse’s reassurance and praise for good control or was used to initiate a discussion with the patient about management where the trend showed some deterioration. Both nurses and patients reported finding this helpful. Echoing the hospital consultant who used a paper template to ensure the completeness of recorded information, nurses said the digital template was useful for making sure nothing was missed during the appointment. Having items on the screen prevented ‘skipping bits’ or forgetting to go back to an uncompleted section before the close of the consultation.

Participants perceived that accessing the HIT system during diabetes review appointments facilitated the nurse– patient interaction, or was neutral. It allowed quick comparisons of new test results with previous results during the consultation, and was thought potentially useful for encouraging patients’ involvement in their own care. Using the HIT system well was seen as part of the health professional’s consulting skills.

‘Part of the skill of using it is that it isn’t a problem. I suppose there could be exceptions, patients who didn’t like having a computer in the room – but I honestly can’t think of an occasion. I can’t think of anyone ever picking me up on it!’ (Family Practice Nurse)

Barriers to and enablers of coding

Hospital coders sampled in this case study were comfortable that they had the necessary training, support and competence to code. They were supported to undertake additional professional qualifications and took pride in their medical knowledge and coding skills. There was evidence of job satisfaction, partly derived from a belief in the importance of what they were doing. The principal barrier they perceived to better coding was the limitations of working from hospital discharge summaries.

Similarly, coders in family practice described good access to support and training, and in their case also having an HIT system that was by and large easy to use because much of the coding was automated.

Being part of a small team in a family practice setting was also seen as helpful:

‘We all know each other and get on. We sit in the same room as each other so if there’s a query or a problem, or you notice something is missing that needs coding, you just ask the person’. (Family Practice Nurse)

Interviewees were asked their views on a government proposal for all NHS organisations in England to change to using a new clinical terminology. The commercial supplier participant was well aware of a proposal to have SNOMED-CT codes used by the whole of the NHS in England in future; however, no other interviewee at the time of data collection knew about SNOMED-CT codes or when any change to using these codes might happen.

‘We haven’t got anybody in the NHS asking us for it, not yet, but we are fully aware and know what to do’. (Systems Supplier)

‘SNOMED? What’s that? I haven’t heard of that. … It’s not on our radar yet!’ (Family Practice Coder)

None of the family practice interviewees indicated that difficulties with using their HIT system posed a barrier to coding for them. One nurse reported there were some ‘niggles’, such as having to click to change screens, but in her experience these were not a problem:

‘No, I’m positive about it’. (Diabetes Nurse)

Clinical and research benefits

Both family practice and hospital clinicians in our study identified some clinical benefits from structuring and coding diabetes data. These related to the availability of information for consultations, disease management by protocol and speed of information sharing in the case of electronic transfers of EHRs for patients moving from one family practice to another. A far greater potential benefit, according to some interviewees, lay in secondary uses of coded data. Clinical interviewees and academic clinicians believed that coding would lead to significant improvements in research, public health, epidemiology, service planning and audit. These participants were based in the case study settings and in academic institutions outside those sites.

‘At the moment, I can’t answer even basic questions about our diabetes patients, unless I go through all the records one by one and can you imagine how long that would take? Coding is fundamental for researchers’. (Hospital Research Nurse)

There was particular enthusiasm for the SCI-DC system in Scotland, which supported regional diabetes registers, prompting screening calls, and research participation through a national patient research register.

‘SCI-DC is the way ahead. Everybody is going to find their way on to it somehow because it uses multiple sources. We can extract more value from SCI-DC by linking. In effect, we have potentially huge cohort studies. There is enormous potential value through linkage for public health’. (Hospital Doctor/Academic)

In addition to cohort studies, interviewees suggested that the availability of a comprehensive dataset of the population with diabetes would lead to wider public participation in medical research and held the promise of easier, faster and cheaper, large-scale randomised controlled trials.

‘The diabetes dataset we have in Scotland is among the best in the world, and researchers from other countries are coming to us now wanting to use it too. It links to other datasets, such as the cancer register and maternal data, which makes it hugely valuable for future research’. (University Researcher)

Strengths and limitations

The strengths of this case study are the range of interviewees who described their experiences and views on data structuring and coding for diabetes and the sampling of three sites from one area (two family practices and one hospital), which gave a picture of diabetes information recording across a local health community. We selected diabetes as an exemplar of long-term, biomedical conditions. As such, our diabetes- related findings may at least some extent be transferrable to other long-term conditions, for instance to asthma, chronic obstructive pulmonary disease and stroke, in which on-going monitoring and disease management by health professionals and by patients are also important factors in care.

The main limitation of the work also relates to the highly variable approaches to diabetes data capture in English hospitals. Our detailed, on-site findings are restricted to one health community in which the sampled hospital used paperbased diabetes records; had resources permitted, it would have been valuable also to sample a hospital in which EHRs were established. Qualitative research elicits the subjective accounts of participants. While this paper provides an accurate account of the interview data we collected, we acknowledge that data saturation was not necessarily achieved. There may be quite different experiences and perspectives that we failed to capture here, despite interviewing a diverse range of clinical and non-clinical participants.