CLICSLIG 7/12/13 ‘The GP systems of the future’

BCS Primary Health Care SG

CLICSIG 7/12/13 The GP systems of the future

The Greyhound, Lutterworth

CLICSIG Objectives

This event was held on 7/12/13 at The Greyhound at Lutterworth with the following objectives.

• What will primary care look like in the future?
  • This will generate new/revised functional requirements
• What are those new or revised functional requirements?
  • interactions with patients and carers, e.g. as typified by the PHCSG’s ‘looking after Fred’ example
• What changes to IT systems will be needed to support them?Advances in technology will provide new options for providing this support,
  • e.g.: telemetry, wearable sensors & processors, always connected technology
•  Procurement
  • will the current/revised GPSoC deliver the systems and functionality we need?

Primary care of the future

• A lot of it will be the same – the recording of patient consultations with practice staff
• But these will occur in new ways, e.g. teleconsultations
• Consultation may be asynchronous e.g. interaction via email, and not necessarily with physical presence of the parties
• Access to diagnostics may change. They might occur before the encounter.
• Access to records may change.
• What is the record (and who “owns” which bit of it)?
• Records will tend towards unification – though there is a tendency in some areas for the hospitals to try to land-grab primary care
• Need for a universal coding system (danger here because terminology may not be used consistently by different care providers). SNOMED supposed to be universal by 2015, but the advice is that this should be behind the scenes rather than in the front, as compositional terminologies painful to use unless heavily constrained by the context of use.
• Increased autonomy of some patients: may become his/herlead carer. Cost of healthcare projected to be greater than GDP by 2050, so secondary care will have to be pushed to primary care, and primary care to self-care for purely financial reasons.
• Creation of ‘local healthcare environments’ with hospitals becoming a healthcare hub and everything paid for by the CCG. This will threaten hospital management because there will be much less need for it.
• If diagnostics become mobile tthe need for the hospital will reduce even further. Mobile vans with diagnostics on board may be an interesting possibility.
• There is a danger of diagnostic vans/operating theatres going round, but leaving the complex stuff for the hospital to pick up
• There may be an expansion of the GPwSI ‘grade’. (note the tendency for the criteria to change so that new qualifications have to be acquired/maintained, pushing out existing GPwSIs.)
• Need to maximum the use of GP data for secondary purposes
• Need to link it with data from other sources for 2ndry purposes
• The general conclusion is that the system of the future will be fluid and therefore we need to be particularly careful to enable this fluidity.

Impact on the record

• Need a joined record but an individual view for the specialist areas (which could be a nurse practitioner view in COPD).
• Special methods needed to access and view these specialist areas
• The record need to be at the right place at the right time
• NHS England have a project called ‘integrated care design’ which may be ‘son of CfH’ – the project has no patient, carer or GP representation.
• If there is a competitive environment between systems then there must be the requirement to have communication between the systems (e.g. open APIs). Companies should not be able to ransom your data and lock you in to their system.
• Therefore we need open standards for data structures and formats. One option is for patients to decide where data is held (they can of course already decide where they hold any data they generate). The analogy with the way that the internet developed implies that development of structure etc can in fact be open. Development of data structures must not be prevented. (e.g. the development of a POMR depends upon having the ability to show that a particular entry is indeed a Problem header, or relevant to a given problem.)
• We have too much data and too little information.
• The presentation of data is separate from the storage and amount of data, and different views are needed for different purposes and for differernt audiences, e.g. a journal view where contact sequence is most important, a problem-oriented view when a particular problem is the topic of consultation.

How do we access the data in the future?

• Problem orientation
• The need for clinicians in the future to be educated in the use of medical records and in their layout, and in how to housekeep (alt. ‘curate’) the record . This sort of activity doesn’t happen in hospitals and in many practices.
• Curating the record is an active, important duty which is continually needed.
• A Summary item is not the same as a Problem header.
• Some kinds of entry /item need to appear under several Problem headers, and problems may need to be nested, e.g. vomiting problem due to current chemotherapy for cancer,
• Need concepts of Major and Minor, and of Current and Dormant which are not necessarily easy to define/housekeep consistently.
• In addition, need a template so that other entries (eg. BP) can be drawn in where relevant even if not labeled as part of the existing problem.
• Need to develop an ‘etiquette’ of grouping this – not mandating this, but developing ‘best practice’ – this may need to evolve.
• The possibility of having several different presentations of the record according to individual need (eg the difference between a POMR and a Major-Minor Problem/summary record). This may be important when a common record is viewed by different organizations.
• How do we get round this? Does the record need to be accompanied by data describing the different views of it that different users or organisations wish to use?.
• Do we rate all data the same? Or does it depend upon who entered it? Clinician B should be to be able to move, annotate, nest, change the appearance of or rename information entered by Clinician A (in a different establishment), but see preceding footnote.
• This also needs the ability to keep/export the ‘tidied data structure’.
• There is also the problem that there may be disagreement between clinicians on how they want the information laid out, or disagree with the implied information caused by a specific layout/nesting.
• The provenance of information (i.e. who said/observed it, when, their professional status) is extra metadata that is important.
• Who has the right to amend/delete a Problem header? – GP, consultant, optician etc.
• Although it would be possible to arrange for lack of tagging to be completely compensated for by much improved search engines, many of our colleagues are not well-versed in the use of the computer and the etiquette of writing records will mean they can’t utilize it properly.
• There are also those who are ‘record vandals’!
• Importance of systems making it easier to enter and structure the entries.
• The difference between those who code a lot and freetext little, and vice-versa.
• There is a danger in over-coding in that it can create a yes/no situation giving an unwarranted degree of certainty. (e.g. ‘an occasional mild cough’ doesn’t necessarily translate easily to cough yes/no.)
• Episodes v. events and the difficulty of terminology. (episodes of care now tightly bound into commissioning and ‘episodes of consultant care’) The danger of poor coding use when using diagnostic codes for review/sharing/treatment. (e.g. regular speech therapy on a Tuesday for a patient who has had a stroke will lead to an apparent weekly stroke for the patient if the therapist adds a diagnostic ‘stroke …’ code to each visit record.)
• We need a published strategy of etiquette for laying out the record, and of the definitions of various elements (such as ‘episode’) (and also the things that have gone wrong in the past, in order to avoid them.)
• Dr Lockley has been requested to create a draft document about the etiquette of laying out the record, on the Wiki at wiki.phcsg.org/mediawiki
• How do we access data held elsewhere, social care, secondary care, held by the patient alone?

[1] Housekeeping would not be allowed to erase anything from the record, but only to remove it from view where necessary (e.g. if it is considered to be wrong, for example. where a test result has been entered into the wrong patient record).

Sharing data with others

• We have to think about data quality, and about how a specific term or piece of data is interpreted by the donor and the recipient(s).
• How much data should be shared?
• Under the DPA, only information relevant to the purpose for which the information is being used should be shared.
• Writing a letter is a particular active clinical and social skill. It’s a half-way house between copying/making available absolutely everything, and not saying enough.
• Always need to be able to remove irrelevant past items (e.g. a termination many years ago in a referral for COPD).
• There is a need in some systems to be able to have a Wizard to assemble a referral, together with the ability to remove what are generally considered likely to be ‘sensitive’ entries.
• SystmOne’s enhanced Data Sharing Model (DSM) is a way of managing the access to medical information from other providers – each patient has a pool of her own data and individual providers can share out into that pool, and share in from that pool. Individual entries can be excluded from sharing, but child protection entries are entirely separate from this and are always and only visible to those with permission to view child protection entries irrespective of the patient’s wishes..
• There may need to be a change in the law regarding Data Controllers because of the impossibility of controlling what happens to the data when it is out of the original controller’s control.
• We believe we need different legislation because of the current situation with regard to care.data and the source data controllers. Most GPs are horrified by NHS England’s demand for identifiable data without patient consent to form the initial component of care.data, and that GPs were being held responsible for this, and for informing patients about what was happening.
• Sooner or later the government will need to be able to extract effectively de-identified patient data for secondary uses that benefit the nation’s health . The data may be anonymised or pseudonymised,
• With the Data Controller’s consent such information, including data held in primary care, should be shared with the NHS and Public Health England.
• Identifiable patient data should only be collected from practices with patient consent, or in (the very rare circumstances) where a respected independent body such as the Confidentiality Advisory Group agrees that identifiable data is essential for the intended purpose, that obtaining consent would be impossible and/or extremely undesirable, and the benefit to the patients concerned and/or the public outweighs the consequences of deliberately breaching the confidentiality of the patients concerned.
• Access via the MIG is charged per record.

Patient record access

• Will the opening the whole of the record to the patient imperil the recording of suspicions, uncertainties, etc? Opinions on this are strongly held and divided. In general not sharing uncertainty with patients and carers is undesirable, but there are scenarios where it is generally agreed that patient / carer access could well lead to patient harm or the GP not recording information to avoid causing harm when and if the patient record becomes open access – e.g. in cases of suspected child or partner abuse, the neurotic patient with a probable cancer. The group was concerned that open access would lead to a decline in the quality of the record, and use of a parallel record (probably on paper) which won’t be shared. On the other hand this does not appear to have been seen as a problem by the open access pioneers, from 1980 (Mike Sheldon), Richard Fitton (1990 onwards), and more recently Brian Fisher and Amir Hannan.
• One possible solution is for the record to be split into two – with the patient-accessible record holding defined, agreed certainties (or perhaps coded entries) and a separate part of the record holding the suppositions, concerns, and ‘messages’ for the clinician and his/colleagues. Dutch GP records include a section for info which the author doesn’t wish to be shared.
• Alternatively the patient could see the coded information but not the free-text (with some codes which are always withheld). These codes are needed to enable automated searching of the data.
• It may be necessary to create permission levels on a single record to achieve this, and it could be more fine-grained – for example, carers may need to see different information to the patient, the GP, etc.
• What is going to happen to all existing data under this scheme? Some of this is highly confidential, some about third parties and some of it is also wrong. Some records could be released easily, but the task of sorting the wheat from the chaff might be impracticable.
• Experience of defining access is that there are actually only about six different styles of access, many fewer than the types of professional and non-professional who access the record..
• Role-based access control is not enough here. There needs also to be the ability to ‘silo’ patients and their information under a legitimate relationship heading..
• Some practices ask people to always put a note on each record they open, to enable a check to be made on why you have viewed it. The commoner option is to have an audit trail logging all those who open a record. A refinement of this is to allow people with a specific legitimate relationship to the patient to view their records without logging the access, tho’ this is not satisfactory where patients are frequently seen by different doctors in the practice.

How is the system going to help me to look after the patient?

• Decision support
• The importance of having a joined-up record which is quick/intuitive to access
• The importance of systems which ‘think ahead’ using multi-threaded technology to minimize/streamline user actions – Importance of it all happening on a single screen, not on a multiscreen application.
• Importance of new guidelines being incorporated into the system essentially immediately – ‘just-in-time’ knowledge: Muir Gray has talked of the impossibility of medicine relying on what a care professional can remember.
• Therefore the system should react to the latest guidance coming out of the knowledge builders, such as the BNF, work out who this applies to and where necessary prepare lists/mailmerges, etc, as well as advising on possible and selected treatment options. Suppliers have a limited willingness to incorporate these features. This may need a separate group of independent suppliers to provide knowledge management in a system agnostic way. Need to develop a consistency about interfaces to avoid confusion. Also need to ensure that a drug recommended for Illness A isn’t recommended if it is contraindicated in illness B which the patient already has.
• There’s a need for filtering/managing/calculating of incoming data to avoid information overload while not missing important changes. Some of the responsibility for this has to be shifted back to the patient and simple algorithms and advice to be given to the patient automatically.
• Formal care planning software needs to be implemented – but to funnel in to one care plan per patient (which they could then automatically display to A&E if things go wrong).
• Importance of developing agreed ways to work out (eg. how long a set of medication will last for) across all systems. Meds review across primary and secondary care.
• The importance of using dose prescribing, rather by the pack size that the pharmaceutical company provides.
• The need for a single central persistent medication database covering primary, secondary and all other care, whether NHS, private or myself-care, in real-time, thereby ensuring that primary care (and everyone else) knows exactly what other care providers are prescribing (especially in oncology) –it’s already in place in Holland for primary and secondary care. This is a safety issue.
• Smartcards have got to go! (They lock you out of using anything other than a desktop, they encouraging multi-using of the same cards, they don’t repeatedly affirm the identity of the user.)
• Importance of guiding people to the correct codes to input – voice processing doesn’t work well for single words, but analysis of phrases helps – this type of technique may be of great value.
• SNOMED not easy to use. Perhaps the use of automatic coding engines will help.
• Beware the possibility that if Read codes are removed and SNOMED forced upon us, the amount/quality of coding may reduce markedly, especially in those practices that are not coding-orientated.

[1] The effectiveness of anonymisation amd pseudonymisation cannot be properly assessed without knowing what other information (especially but not only identifiable patient information) that the intended user(s) either hold or have easy access to, and what they intended to use the data for..