Are new diabetic codes available on GPASS, are they changing them again?
New diabetes Read codes were created last year. These are for Type 1 and Type 2 diabetes
(C10E. and C10F). There are no further new codes for these although there have been a lot
of other new codes recently created, specifically to allow software providers and practices to
record appropriately for the Contract. GPASS schedule new Read codes to be incorporated
into GPASS releases and the current release has all of these included. With the phased
nature of GPASS releases, for a few weeks it is possible that some practices will have the
new codes whilst others won't.
There are 2 codes for type 2 diabetes. C10F & C109. Both are in the new read code
formulary. We have been using C109 but only C10F registers on Spice screens.
Similarly for Ischaemic heart disease, 2 codes: G3 & G3z. We have been using G3
but only G3z registers on Spice screens. CDSS recognises both codes for each
disease area. Is this another bug that will be rectified with next GPASS update?
C10F has replaced the original code C109. as it is a more 'correct' code to use in the
diagnosis of Diabetes. The GMS Contract does pick up both codes but the Scottish Diabetes
Dataset and the SCI-DC project are keen to encourage the use of the new codes and will
eventually phase out searching for the old IDDM and NIDDM codes. It is sensible for
practices to start adding the new codes and there is no need for them to modify or delete the
old codes they have used.
CDSS have recently introduced new functionality to their screens, which allows you to see all
the possible codes but recommends only a few. This does improve the usability of the
screens but it is currently not possible with the Care Management screens. GPASS are
undertaking a complete review of the screen functionality and this may be one of the future
On the CHD screen there are C's next to IHD and Angina. How important is it to label Angina'
C'? When you have Angina, you are automatically labelled as having IHD, so the IHD code
has been given to patients and Angina has been put in the extension
There is less need for a 'C' next to both the IHD and the Angina fields. Initial DOH search
specifications (July 2003) the angina codes were quite a small subsection of the IHD codes
so it was more relevant. However more recent (latest = Feb 2004) search specifications have
increased the angina codes. The angina codes are now essentially all of the IHD codes
except for any codes indicating the patient has had an MI. Previously it would have been
possible to code someone as IHD but not angina so they would not have been included in
patients requiring exercise tolerance tests. Practices need to be aware that coding a patient
as IHD or Angina or both - for new diagnosis since 1.4.03, they will be included in the CHD2
In the asthma template in SPICE we're asked to confirm diagnosis, the only options
given are peak flow/spirometry or salbutamol reversibility. Could read code 8BBz. be
added as I thought response to treatment was also in the contract as confirmation of
diagnosis. This is obviously significant in children where the other tests are not
8BBz. (Response to treatment NOS) is not a code that would be picked up in the contract
searches for this indicator (as specified by the DOH publications Jan 2004) therefore we
cannot include it in the dropdown choice. The only way would be if it were put forward and
accepted by the DOH for future inclusion in the searches. However I think this very unlikely
because it is too vague a term - not relating specifically to asthma or to a type of treatment.
For example, this code could equally be used for a depressed patient responding to ECT.
What is the difference between H33zz Asthma NOS and H33z Asthma unspecified? What is
the definition of each and when should they be used?
For new contract purposes a variety of Read codes are available. For new entries use the
preferred code, (the SPICE screens display the preferred code.) Other codes although not
preferred codes are in the basket of acceptable codes and will be picked up by Business
The general policy is to chooser the preferred code, a code which is as far down the hierarchy
as is possible. This avoids the danger of codes below in that hierarchy being inappropriate.
Hence H33z Asthma unspecified means the same as H33zz Asthma not otherwise specified
(NOS) but the latter is the preferred code.
A practice has indicated that they wish to use H33. from the SPICE screen. Can you tell me
why they cannot and if this is going to change?
The SPICE screens have been carefully designed to select the new contract preferred code
hence the use of H33zz. although H33z is also an option. In this context it is irrelevant which
is chosen although H33zz is the preferred SCIMP code. Both BO and CALM will pick up
patients with any code beginning H33 i.e. H33% but this code will not be displayed in the
asthma SPICE screen. There is no need to change these as the approved code can readily
be selected at the first routine review of the patient over the next year.
These 2 codes G33z. and G33zz were both on the original SPICE screens, which pre-dated
the contract. Either is acceptable for the contract although G33zz is preferred. We did
consider removing G33z. to avoid any confusion. However this would have meant that
practices who had previously used this code would no longer find it shares to the Care
management screen, so the decision was to leave as it is for the present. We have tried to
make as few changes to the screens as possible. At present there are no plans to add
G33..as there is a risk this may add more confusion over which code to use. However
screens are being almost continually reviewed.
Ex-smokers have been recorded by putting the date they probably had their last
smoke as: eg, 'smoker ...1999’ and another entry in as 'ex-smoker ....2000'. Does
the contract look at the most recent date for smokers or would it pick these people up
as smoking and ex-smoking?
The Contract search specifications (Jan 2004) look for any one of the 'current smoker' codes
being the most recent date entry of any of the smoking codes. Therefore if a patient has a
code for 'ex-smoker' dated after the date of the most recent 'current smoker' code - this
patient will not be picked up as being a smoker.
There is confusion about how the start date will work in the reports. Will it look for a start date
for all MI, stroke, and cancer codes after 01/04/2003 or will it look for a start date for each
patient, and if it finds a start date will it ignore all other codes?
The BO logic is as follows:
Check if start dates in relevant code or group of codes. If more than one start date choose
most recent start date. If no start date select earliest date of recording.
Epilepsy data has been input through SPICE but doesn't appear to be showing in BO. The
indicators which are not showing up are Epilepsy 2 and 4.
Also BP2 - a practice with 242 hypertensives ran a search to find they had a smoking history
on 240 of them. BO reports showed they only had 161 with smoking history. I notice that this
is also a problem with CALM. Are BO problems the same as CALM - are they both using
reporting database and same criteria for missing indicators?
In the specification to the programmers the smoking status must be recorded post the date of
diagnosis - it does not state this in the blue contract books.
Epilepsy 2 and 4 are a known problem. Note - the medication review for Hypothyroid,
Epilepsy and Asthma must be ticked in the SPICE screens, not the repeat prescribing
screens as different read codes are used.
Should we code patients who are on thyroxine, because of lithium therapy, as acquired
Yes, they will require the appropriate monitoring for hypothyroid disease and this seems the
most appropriate code. As the Contract population also depends on them being on thyroxine,
should their hypothyroidism resolve because they stop their lithium (therefore they stop
thyroxine) they would no longer be in the population.
A new hypothyroid screen was going to be updated so that there would just be a tick box to
say thyroid function had been checked. Will the BO still pick up those patients in whom we
have entered an actual result?
This was added because the contract search specifications do not require values entered for
this however the Care Management screens and SPICE has previously entered values for
this and these were looked for in the reports. I'm afraid I can't answer for what the BO reports
will do in the future but certainly the SPICE reports will continue to look for values. I will
forward this on for further advice re BO. Once the lab-links is up and running this will no
longer be a problem as every result will be automatically linked to a specific read code.
Why are the ca in situ codes are not included in contract query spec, namely B852 ca in situ
skin of breast and B834 ca in situ of prostate?
None of the B8 or BB codes are included in the spec
Which codes should be used for ca. prostate and breast cancer?
Cancer of the Prostate - B46
Cancer of the Breast - B34
The codes specified for ca-in-situ are for the premalignant cancers – which are outside the
scope of the Q&O. Ca-in-situ codes should not be used as this is not an invasive tumour but
rather a pre-invasive stage which may or may not progress. The codes you need are for
"malignant tumour of prostate" and "malignant tumour of female breast". The latest April 2004
contract codes are now on the SCIMP website click on "Read Codes" to access and
A patient has LVD, they have had an echocardiogram, when entering it in SPICE the only
options are U-S heart Scan and abnormal echocardiogram, the GP's don’t know what U-S
Heart Scan Stands for, and if the result is normal what should they put it in as?
U-S heart scan stands for Ultra-Sound Heart Scan and is the preferred term for the code
5853. which is one of the accepted codes for the official GMS contract searches. This code
does have the synonym term 'Echocardiogram' but the contract documentation dissuades us
from using synonyms - but they are the same thing. The code 58531 (Echocardiogram
abnormal) is also acceptable for the contract searches. It is up to a practice to decide whether
they wish to just record that a scan has been done or be more detailed with the actual result.
Before the contract we used the code 58530 (Echocardiogram normal) but this is not one or
the recognised codes to meet the contract indicator so it was removed. This is because if the
Echo is normal it throws into doubt the diagnosis of LVD. However it may be reasonable for a
practice to enter this code via the normal read code entry system if they wish.
A CMR practice has numerous diagnoses for angina on the system, this however
means that indicator CHD 2 becomes active even though the patient doesn't need an
ETT. Once the correct BO logic is in place the date taken for each group of codes will
be the earliest date recorded for this basket of codes. Is this a known issue and what
is the best way around this (should the practice be recording 'chest pain' etc)
The practice should carry on as at present and be reassured that the BO logic will
soon be corrected. The only changes necessary are the ones often discussed that
practices must use start date for NEW diagnoses of MI Stroke and Cancer.
We have a version of the exception codes dated August last year which has four
exception codes for each disease area (eg for CHD we have 9h0 - Exception
reporting - CHD indicators, 9h00 - excepted from CHD Indicators - patients refuses,
9h01 - excepted from quality indicators - patient unsuitable, and 9h03 - excepted from
quality indicators - informed dissent. When we look in Gpass however, the 'patient
refuses' option is not available. Are there plans to incorporate this into GPass
(perhaps in 5.5) or have they been deleted?
My understanding is that all the exception codes for the new contract will be
available in GPass V 5.5.
Why is the 'patient refuses' option not available to select while a document we have
from the end of last year was indicating that this code should be available along with
the other options in 5.4 phase four?
These codes were included in the October release of new codes. There are only 3
exception codes created for each disease area, an overall exception code and then
one each for 'patient unsuitable' and 'informed dissent' .It is not the case that GPASS
hasn't included the codes for 'patient refuses' but rather that these have not been
created as codes. Either the code for 'informed dissent' should be used in this
instance or the overall code (top of hierarchy for each disease exception) with
explanatory text added in the extension box.
A patient who suffers from multiple chronic diseases has refused to be seen by their practice
nurse. He is being seen in secondary care for his diabetic care. Should this patient be
excluded from practices' disease register using "informed dissent" code or is there an
exception code being developed to include patients whose follow up is in secondary care?
Patient should be coded as informed dissent – perhaps with some mention of why or letters
sent, put as free text into the extensions box. The ideal would be that the patient signs a form
confirming their wish not to attend review at the surgery, but this is not always feasible. This
code would need to be added every 15 months and in theory the patient should have been
reassessed re their dissent every 15 months.
However, information contained in the hospital letters such as BP, smoking status, wt etc
should be entered with the appropriate dates, as these will then count for specific indicators in
any of the disease areas and also for the organisational indicators. The patient will only be
excluded from indicators that you don't have information for. There are certainly no codes in
the searches for reviews in secondary care.
Why is echo normal going to be removed from the updated IHD screen? Isn’t it good to be
able to see when looking at previous MI patients etc that they had had an ECHO & therefore
left ventricular dysfunction had been excluded?
This field is marked as being relevant for the contract and is specifically to show that a patient
with a diagnosis of LVD has had this investigated/diagnosed via an Echo. It was not intended
to use for CHD patients who have had LVD disproved - although this would be useful. The
codes for Echo normal are not codes that would be detected in the contract searches (codes
determined by DofH publications) and so they could not be recommended for entry in this
field. The fields for LVD and Echo were included in the CHD screen (they also appear on the
LVD screen) to enable practices to enter for this sub-section of CHD without having to open
Input info – Spice screens
Practices wanted to do a chronic disease review, input the information directly into spice
screen and write in the notes, i.e.: diabetic review see spice screen. Do they also have to
write information on "pink sheets" in notes? I wasn't sure of medico-legal implications in a
practice which is not paperless.
Practices need to decide whether they wish to keep computer, paper or both records. The
computer recording means that data is very structured; drawbacks are possible loss in
recording of some of the 'softer points' within a consultation eg. social problems. It is possible
to print out a Care Management screen with the data entered but this rather defeats the
purpose of reducing paper. For further guidance see SCIMP ‘Good Practice Guide’.
* A Practice informed me, they do not do a first cholesterol or microalbumin on patients over
80 (as per practice guidelines), but wonder if they will be penalised or if they can exclude
these patients and which exclusion code would they use- would it be the frailty one as this is
not strictly the case it is merely that there are clinical guidelines which state these tests do not
need to be done.
* A GP informed me after attending a course, if you excluded a patient from one disease area
they were automatically excluded from them all. Is this only the case if you use the
"terminally ill" exclusion?
I assume this relates to Diabetes, IHD and Stroke for Cholesterol and just Diabetes for
microalbumin. There have been specific read codes developed to exclude patients for each
disease area. These are in the 9h... heirachy. These are fairly new and it is possible they may
not yet be available to some practices - depending on which GPASS release they have. Each
disease area has 3 possible codes, for example Diabetes has:-
9h4.. (Except report: diabetes quality indicators)
9h41. (Except diabet qual ind:Pt unsuitable)
9h42. (Except diabet qual ind:Informed dissent)
These are the only codes used as general exceptions for Diabetes as specified in the
DOH search specifications. There are no general read codes that exclude patients from
all disease areas in the contract search specifications. This means that from the current
DOH documents there is no exclusion of code for terminal illness - they would have to
use the '..Pt unsuitable' codes as above and add one for each disease area as
appropriate. I would think it useful if a practice does note why the patient was considered
unsuitable - and this could be done by free text into the extension box for the read code
eg. 'frailty, terminal illness'etc. One important point is that, even if a patient has been
exclusion coded from a disease area, if a specific criterion has been met, that patient will
still be included for that criteria but excluded from the rest. i.e. A patient may have refused
to attend for asthma review and had the appropriate code added but opportunistically
their smoking status has been recorded – therefore they will be included in the figures for
smoking status recorded within the asthma report but not the rest.
A practice is using the new 'asthma resolved' codes to exclude patients from the asthma
population. This is included in the contract definition for asthma (similar codes also for
hypertension, epilepsy, diabetes). They have not yet been able to get BO to work, so have set
up their own practice searches. If a patient has had an asthma resolved code and then
subsequently their asthma comes back and they are re-coded asthma they will then be back
in the asthma population. How can a GPASS search be set up that looks for an Asthma code
after the date of the 'asthma resolved' code. They would like to generate a list of patients from
From Gpass searches I don't think you can. The reporting db will give you it (using access).
The disease register extract tool I had written is going to be rolled out to all practices through
Gpass. I haven't yet updated it to meet the changes with the resolved codes. What I was
planning on doing was excluding these patients from the disease register, but adding 4 extra
queries to show the list of the four resolved groups.
Do you think it is essential to change the software to exclude the resolved before practices
I didn't think this could be done through a GPASS search either. These 4 disease areas
(asthma, diabetes, hypertension and epilepsy) are the only ones where resolved codes have
actually been created and specifically included in the contract searches. It is possible,
although not frequent, for all of these to resolve - for example an obese person with diabetes
and hypertension could resolve both with good weight loss and a healthier diet / lifestyle. For
asthma it would also be possible but rare for a patient to have received medication in the last
year but to also have a resolved code.
These codes have only recently (Feb 04) been added to the contract searches. It’s not
essential that they be added into the searches right now.
The contract documentation lists G65% as one of the contract codes however, it has been
said that G656 (Vertebrobasilar Insufficiency) should not be counted as a stroke. Patients
with this code will be identified for the Stroke/TIA disease register, and therefore, be
monitored to achieve targets for the contract. Does this code definitively mean that the patient
has had a stroke? If it turns out that Vertebrobasilar Insufficiency is not a type of stroke or
TIA will it be removed from the basket of codes that Business Objects searches on?
The most recent documentation does not include G65% but does include G65-G654 thus
does not include G656 vertebro basilar insufficiency. see web site -
If it is currently in the basket of Read codes for BO it will be removed.
The current criteria for the contract (basket of codes) finds all of these.
G65.. S Drop Attack
G65.. S Vertebro-basilar insufficiency
G650. P Basilar artery syndrome
G650. S Insufficiency - basilar artery
G651. P Vertebral artery syndrome
G6510 P Vertebro-basilar artery syndrome
Should these other diagnoses (G650% or G651%) be classed as a stroke?
The answer is no. Please see below
No % (all codes below) in G65 codes.
We are in the process of ensuring the BO searches correspond with latest guidelines as on
DoH site - <http://www.doh.gov.uk/gmscontract/infotech.htm> (Stroke disease codes) Code
criteria Qualifying diagnostic codes Read codes v2
From the contract documentation I know that they have only looked at the preferred terms for
codes in agreeing the codes for searches, and don't consider synonyms. There are certainly
quite a lot of cases in the Read hierarchy where there is a degree of interpretation as to how
much the synonym meets the preferred term for a specific code. If a practice has used G65..
for 'drop attack' but don't intend it to mean a TIA then I think this has to be considered an
error in their coding and should be changed. As to whether 'Basilar artery syndrome' (G650.)
and 'Vertebral artery syndrome' (G651.) and 'vertebro-basilar artery syndrome' (G6510)
should be in the searches.
This was received from SEHD in July 2004
Read Code G65. and Synonyms
1. This note discusses an issue that has arisen during the construction of the datasets and
logical query specification for QMAS. It concerns two terms linked to Read code G65..:
G65..00 Transient cerebral ischaemia
G65..13 Vertebro-basiliar insufficiency
2. G65..00 is the preferred term (hence the 00 suffix) and is one of the main target
conditions for the stroke section of the QOF and has been included in the stroke dataset.
G65..13 is a synonym of G65… Not all patients with this diagnosis - and hence this Read
code in their record - will have a condition that is a target condition for the indicator
domain (i.e. stroke or TIA). However, some will do and the challenge is to devise a
method for including those patients with a relevant condition.
3. There are three options for implementation of QMAS:
(i) Include all instances of G65.. irrespective of whether the preferred term or a
synonym is used. This is incorrect as some of the patients with G65..13
Vertebro-basiliar insufficiency do not need treatment as if they had transient
(ii) Exclude all instances of G65..13 Vertebro-basiliar insufficiency. This is also
incorrect, as some of these patients do need treatment.
(iii) Include all instances of G65.. but advise users that exception reporting is used for
those patients with G65..13 Vertebro-basiliar insufficiency who do not require
treatment. This is our preferred option as it includes all relevant patients whilst
excluding those for whom treatment is not applicable. The exception code 9h21.
(Excepted from stroke quality indicators: patient unsuitable) would be
recommended to be used.
4. GPC are asked to confirm that they are content with this proposed approach. We will
communicate this via GP clinical systems suppliers.
DH and NHS Confederation
6 May 2004