business rules supporting information - digital.nhs.uk€¦ · web viewthese documents contain...

Copyright © 2017 Health and Social Care Information Centre.The Health and Social Care Information Centre is a non-departmental body created by statute, also known as NHS Digital.

Business Rules Supporting Information

Published April 2017

Version 1.2


ContentsAmendment History 31. Background 42. Dataset 6

Qualifying Dates 6Patient selection criteria 8GMS Registration Status 8Populations 8Clinical code clusters 9Clinical data extraction criteria 10Producing the Dataset 11

3. Data Exports/Outputs 12

Indicators 12Payment Counts 13Management Information Counts 13Patient-level Extracts 13

4. Rule Logic 14

Processing rules 15

5. Performing calculations using dates 186. Special Syntax 25

Arrays 25Maximum/Minimum Value in Timeframe 27

7. Further Resources 28

Published by NHS Digital on behalf of NHS England of 29


Amendment History


Version Date Amendment history1.0 31/03/2016 First version of Business Rules Supporting Information

1.1 12/08/2016

Document updated with further notes added around: Background Patient selection criteria GMS Registration Populations Clinical data extract criteria Patient Level Extracts Calculating date of birth ranges for eligible populations

1.2 01/04/2017Document updated with further notes added around:

Calculations relating to dates of birth on 29th February Arrays – fields with square brackets


1. BackgroundThe dataset and business rules documents produced by the NHS Digital Primary Care Domain Specification Development Service are created primarily for the uses of GPES and GP system suppliers. These documents contain specifications to communicate technical details of extracts from Primary Care systems which are most commonly, but not exclusively, used to provide Practice-level information regarding services and/or allocate rewards, such as payments or QOF points.

Business rules are not intended to be used in place of clinical guidelines, but may be referred to by any individual or organisation to aid understanding of which patients and/or activity are included in each population or output.

The business rules registers for QOF and Enhanced Services are constructed solely for the purpose of supporting the practice, GP Suppliers, and NHS England in fulfilling the claims and audit requirements for the indicators. Therefore, while a register may carry the name of a particular disorder for business rules purposes, it may well not be sufficiently precise to encompass all of those patients who might be clinically assessed as requiring follow-up or clinical intervention. It is advised that where a practice wishes to construct a register for the purposes of call, recall and clinical management that it is patient based rather than solely ‘disorder’ based.

Business rules are written and published by NHS Digital on behalf of our customers. These documents consist of two main sections; the Dataset specification and the Outputs. The business rules support analysis of extracted data to reflect the status, at a specified point in time, of patient records held by the practice.

Business rule documents are created for a number of services, such as;

Quality and Outcomes Framework (QOF)A ‘QOF year’ is defined as the period from 1st April to 31st March. Further information and guidance surrounding each of the QOF Quality Services can be found on the NHS Employers website through the following link:

http://www.nhsemployers.org/your-workforce/primary-care-contacts/general-medical-services/quality-and-outcomes-framework

Indicators No Longer in QOF (INLIQ)The INLIQ Quality Service consists of indicators which were previously part of the main QOF service. These indicators were retired and are no longer used to calculate QOF points allocation, but the information is still required to be collected and reported on.

Enhanced Services (ES)Covers additional services that practices can choose to provide. ES can be commissioned nationally or locally to meet the populations healthcare needs. ES require an enhanced level of provision above what is required under core GMS





contracts. Further information and guidance surrounding each of the ES Quality Services can be found on the NHS Employers website through the following link:

http://www.nhsemployers.org/your-workforce/primary-care-contacts/general-medical-services/enhanced-services

Vaccination and Immunisation Programmes (VI)A number of programmes are commissioned for delivery by general practice, including some which are legally directed by the Secretary of State for Health to establish or offer, and some which NHS England has prescribed. Further information and guidance surrounding each of the Vaccination and Immunisation Programmes can be found on the NHS Employers website through the following link:

http://www.nhsemployers.org/your-workforce/primary-care-contacts/general-medical-services/vaccination-and-immunisation

Core Contract Components (CC)Covers services which Practices are expected to provide as part of their contract.

Patient-level Extracts (PLE)A small number of services which require all or part of the information to be returned at patient-level are also specified using the business rules.







2. DatasetThe dataset specification is outlined in section 3 of the business rule documents and specifies the core data expected to be extracted by the system supplier. This is comprised of five main sections;

Qualifying Dates GMS Registration Status. Populations Clinical code clusters Clinical data extraction criteria

Qualifying Dates

The dataset and indicator or count logic (rules) use a number of dates to determine the relevant period(s) to extract data for and for identifying which activity to include in each extract. These dates may differ for each Quality Service and are specified in section 3.1 for use in the remainder of the dataset and rules. Dates may include any number of the following:

Term Definition

Quality Service Start Date (QSSD)

The first day of the period during which a GP Practice provides the Quality Service

Quality Service End Date (QSED)

The last day of the period during which a GP Practice provides the Quality Service

Quality Service Period

The period during which a GP Practice provides the Quality Service specified in this document.

Quality Service Data Extract Frequency

The frequency of data extracts associated with the Quality Service

Quality Service Payment Period

In any given Quality Service Period there may be one, multiple or no payment periods. This is alternatively expressed as a ‘frequency’ such as monthly, quarterly etc.

Payment Period Start Date (PPSD)

The first day of each period for which payments are made for the Quality Service. (i.e. for monthly payment periods, the PPSD will be the 1st of the month in question). Where there are no payment periods (e.g. where payments are made as part of core contract) the PPSD denotes the first day of the extract period in question.



Term Definition

Payment Period End Date (PPED)

The last day of each period for which payments are made for the Quality Service. (i.e. for monthly payment periods, the PPED will be the last day of the month in question). Where there are no payment periods (e.g. where payments are made as part of core contract) the PPED denotes the last day of the extract period in question.

Achievement Date (ACHV_DAT)

The date up to which patient information is considered when determining the output for each extraction. This is usually the same as the RPED; however, where interim extracts are made the achievement date will vary for each extraction.

Reporting PeriodThe full period which data is being extracted fori.e. the time between the Reporting Period Start Date (RPSD) and Achievement Date (ACHV_DAT)

Reporting Period Start Date (RPSD)

The date from which certain patient information is considered for the reporting period in question. For non-cumulative* data extracts this relates to the

extract frequency (e.g. for a monthly data extract the RPSD will be the 1st of the month in question).

For cumulative* data extracts the time period will usually equal the QSSD or PPSD (e.g. for a within quarter cumulative count the RPSD is the first day of the quarter, for an annual cumulative count the RPSD is the QSSD)

Reporting Period End Date (RPED)

The last date of the period the extract relates to (usually the last day of a month e.g. 30th April, 31st May, etc).

* Non-cumulative data collections are self-contained extracts for a given period of time. There is no overlap between one extract and the next and they each have different RPSDs and RPEDs. Cumulative data collections start from a set point in time and the period over which data is collected increases with each extract over the Quality Service period until the final extract. When a new Quality Service period begins the RPSD is reset. Cumulative counts often share a RPSD but have different RPEDs.

In addition to using these dates to determine the core dataset, the business rules have been compiled with a prior assumption all of the dates in the table above are specified prior to extraction of data and are available for computation in the data extraction routine. The dates are required to be included in the data extraction to support processing of indicator/count rules that are dependent upon them.



Patient selection criteria The patient selection criteria detail the required registration status as well as the patient populations. Further criteria detail the clinical aspects of interest for these populations as defined by clusters of clinical codes.

All data is expected to be returned at Practice level unless otherwise specified. If an extract is expected to be returned at another level, such as GP level or patient level, then this will be detailed under the Patient selection criteria heading.

GMS Registration StatusThis section predominantly contains the GMS registration status criteria. This is to determine the registration status at the time of the achievement date, of the patients registered to the practice on the date the extract takes place. All populations are applied to these criteria unless otherwise specified.

GMS registration status will be specified in the following format and may use clinical code clusters and/or dates from the qualifying dates, clinical code clusters or clinical data extraction criteria tables.

Qualifying criteria Action if true Action if false Non-technical Description

Rule logic to determine which patients are included or excluded

Select /Reject /

Next rule

Select /Reject /

Next ruleNon-technical description of the rule

End of rules

NOTE: Non-technical descriptions of rules are provided as supplementary information to assist non-technical readers (e.g. GP practice staff, area teams, etc.) to interpret the logic. Any orgnisations or individuals who are implementing the business rules are expected to implement the logic/qualifying criteria and should not rely on the textual descriptions which may be over-simplified.

PopulationsPopulations consist of either case registers or cohorts. These are subsets of patients to which further logic may be applied to produce the outputs.

Standard business rule logic is used to select appropriate patients into the population. Populations have the ID, title and which patients the logic is applied to in the first table with the logic in the second table.

Register/Count Name Description Applied to patients in:

XXX_REG Title Name of other population ORthe Patient selection criteria.



Rule number Rule Action if

trueAction if

false Rule description or comments

1Rule logic to determine which patients are included or excluded

Select / Reject /

Next rule

Select / Reject /

Next rule

Non-technical description of the rule

End of rules

For further information regarding processing of rule logic see section 4.

Any service may have one or more populations and some populations may be applied to other populations (e.g. a case register with two age cohorts applied to it). Each patient must only appear in a population once; however, if there are multiple registers a patient can appear in more than one register if they meet the selection criteria in each set of rules.

Populations may be referred to as registers or cohorts; however, they are specified and extracted in the same way.

Cohorts are lists of eligible patients that usually form a patient population for subsequent Payment and Management Information counts. These are populations solely for the purpose of the business rules in question and are not recognised case registers.

A list of patients selected into the population, which subsequent outputs can be applied to, and a count of patients selected into the population should be returned for each Population.

All populations are expected to return a count.

NOTE: Non-technical descriptions of rules are provided as supplementary information to assist non-technical readers (e.g. GP practice staff, area teams, etc.) to interpret the logic. Any orgnisations or individuals who are implementing the business rules are expected to implement the logic/qualifying criteria and should not rely on the textual descriptions which may be over-simplified.

Clinical code clustersAlthough clinical codes may not be required to be returned as part of the output they need to be specified in order for any dates associated with them to be identified. Clinical code clusters are specified in a table with their name, description, Read V2 and CTV3 rubrics and the version of the cluster.

Cluster Name Description Read V2 CTV3 Cluster Version

NAME_COD Description of codes included in the cluster Cluster string Cluster string Version number



In the cluster strings, wild cards and ranges are used:

Where a ‘%’ wildcard is displayed, the Read Code is filled to 5 characters with full-stops. When implementing a search for the Read Code, only the non full-stop values should be used in the search, For example, a displayed Read Code of c1...% should be implemented as a search for c1%, i.e. should find c1 and any of its children.

Where a range of read codes are displayed, the Read Code is filled to 5 characters with full-stops. When implementing the search, only the non full-stop values should be used in the search, For example, a displayed Read Code range of G342. – G3z.. should find all codes between G342 and G3z (including any children where applicable). Note: ranges only apply to Read V2 and not to CTV3 codes.

Clinical data extraction criteriaThese are the data items to be exported from the clinical system for subsequent processing. The information provided to enable the initial export is as follows:

Column Content

Field Number Identifier of extract columns

Field Name

Name of data item. Each field name will have a suffix, e.g.:_DAT for dates_COD for clinical codes_VAL for values_AGE for patient age

Code clusterIf the field relies upon code clusters, the cluster reference IDs are specified in the ‘Code cluster’ column (see Clinical Codes for more information).

Qualifying criteria

The qualifying criteria specifies any limits applied to the field. Typically these relate to dates and refer to the ‘EARLIEST’ or ‘LATEST’ occurrence of an event; however the qualifying criteria may also relate to values associated with the data being extracted for the chosen field.

The “ALL” statement is used to select every occurrence of codes or dates. It selects an array of instances, of which there may be more than one for each patient.

Description The description gives a textual ‘non-technical’ explanation of what is required to be returned for the field.



Non-technical descriptions are provided as supplementary information to assist non-technical readers (e.g. GP practice staff, area teams, etc.) to interpret the logic. Any orgnisations or individuals who are implementing the business rules are expected to implement the logic/qualifying criteria and should not rely on the textual descriptions which may be over-simplified.

Producing the DatasetAs we have seen there is a process that selects patients of interest based on population definitions using dates and clusters of clinical codes. For these patients various attributes are populated again using dates and clusters of clinical codes. This should be visualised as a report table where for every patient selected there are rows detailing the data items defined in the clinical data extraction criteria section.

Where there is no data to match a specific clinical criterion a null field will be exported. If a Data item has a NULL value and is used in the Qualifying Criteria of another Data item then the dependent data item fields will also be NULL as dates cannot be checked against a NULL value.

Each selected patient will be represented by a single row in the report, unless the operator “ALL” is used (see Arrays section).

Figures are expected to be reported for both populations and outputs unless otherwise specified in the business rules.



3. Data Exports/OutputsThere are a number of different exports which serve different purposes and will vary depending on the type of service. For example, QOF and INLIQ Quality Services will usually have indicators whereas other Quality Services will usually have a combination of payment counts and management information counts.

Each type of data export has a name and description and will state which population the rules should be applied to. This is usually the Core Dataset, a Register or a Cohort. Types of output include:

IndicatorsEach ruleset may have one of more indicators. These indicators may comprise:

a single count of patients meeting the criteria a numerator and denominator combination producing a fractional figure a Boolean TRUE/FALSE result

Separate rule tables will be specified for the denominator and the numerator populations. Where the register size applies to an indicator, this is the base denominator population for that indicator.

Indicator ID Description Applied to population:

e.g. XXX001 Indicator Title Name of other population ORthe Patient selection criteria.

Denominator

Rule number Rule Action if true Action if false Rule description or

comments

1Rule logic to determine which patients are included in or excluded from the denominator

Select / Reject /

Next rule

Select / Reject /

Next rule


End of denominator rules

Numerator


comments

1Rule logic to determine which patients are included in or excluded from the numerator

Select / Reject /

Next rule

Select / Reject /

Next rule


End of numerator rules



Payment CountsA Payment count is a single figure used for calculating payment and is applied to the patients defined in either the Patient Selection Criteria, a specified Cohort or Register.

Management Information CountsManagement Information counts are additional (non-payment) single figure counts and are applied to the patients defined in either a specified Cohort or Register.

Both payment counts and management information counts have the following structure in the business rules:

Count ID Description Applied to population:

e.g. XXXMI001 Indicator Title Name of other population ORthe Patient selection criteria.


comments

1Rule logic to determine which patients are included in or excluded from the count

Select / Reject /

Next rule

Select / Reject /

Next rule


End of rules

Patient-level ExtractsPatient level extracts have three tables:

1 Extract Details – patient-level extracts are applied to populations in the same way as other outputs

2 Logic – these extracts may have additional logic applied to them to further specify which patients should be extracted if this is a subset of the patients identified in the population

3 Data items - A third table is used to specify which information is to be extracted for each patient. This is based on a four table model (patients table, journals table, referrals table, encounters table). The data items are the fields specified in the clinical data extraction criteria table and the data description column provides a plain English description of the data expected to be returned for each of the rows in the table.

Extract ID Description Applied to population:

e.g. XXX001 Indicator Title Name of other population ORthe Patient selection criteria.




trueAction if

false Rule description or comments

1Rule logic to determine which patients have data extracted or do not have data extracted

Select / Reject /

Next rule

Select / Reject /

Next rule


End of rules

Item Number Table name Data item Data Description

1 Patients

2 Patients

3 Patients

4 Journals

5 Journals

6 Journals

7 Referrals

8 Referrals

9 Referrals

10 Encounters

11 Encounters

12 Encounters

End of extract fields

NOTE: Non-technical descriptions of rules or data descriptions are provided as supplementary information to assist non-technical readers (e.g. GP practice staff, area teams, etc.) to interpret the logic. Any orgnisations or individuals who are implementing the business rules are expected to implement the logic/qualifying criteria and should not rely on the textual descriptions which may be over-simplified.

4. Rule LogicWhere there are multiple rules in the logic they are to be processed sequentially. Processing of rules should terminate as soon as a ‘Reject’ or ‘Select’ condition is encountered. A count should be returned for each Select statement. In QOF rulesets reject statements also generate a count.



Rules are expressed as logical statements that evaluate as either ‘true’ or ‘false’. The following operators are required to be supported:

a) > (greater than)b) < (less than)c) = (equal to)

d) >= (greater than or equal to)e) <= (less than or equal to)f) ≠ (not equal to)

g) ANDh) ORi) NOT

Rules asking for X OR Y should be treated as meaning ‘X and/or Y’, i.e. that either X can be true, Y can be true or both X and Y can be true for that rule (or that section of the rule) to evaluate as true.

If a data item has a NULL value and is used within the rules or qualifying criteria of another data item then this part of the rule must evaluate as false as values cannot be checked against a NULL value.

e.g. if a rule in one of the counts is checking that the earliest treatment took place after the earliest assessment and the patient has no assessment date (null), it is not possible to check whether the earliest treatment took place after the earliest assessment. This means the rule would evaluate as false.

Processing rulesThe following example shows how patients would be selected or rejected by a series of rules. In this example patients are being selected into or rejected from an indicator. It is assumed that the Practice has 7,000 patients and a population (register in this case) called ECZEMA_REG consisting of all patients with a diagnosis of severe eczema has already been identified and contains 100 patients.

Indicator ID Description Applied to population: IN OUT START

ECZ001Patients with severe eczema who were given Treatment X

ECZEMA_REG N/A N/A 100

At the start of the rules there are 100 patients in the register but none have been selected into the count yet and none have been rejected out of the count yet.

Denominator


trueAction if

false IN OUT REMAINING

1 If TREATX_DAT >= ECZEMA_DAT Select Next rule 70 - 30

The first denominator rule takes all patients in the ECZEMA_REG register (n=100 i.e. the START number from the indicator table above) and identifies whether these patients received Treatment X



(TREATX_DAT) after their diagnosis date (ECZEMA_DAT). If 70 patients had received the treatment on or after their Eczema diagnosis date then the rule

evaluates as true for these patients and they are selected into the count so 70 are in the count and processing ends for these patients.

For the remaining 30 patients they did not receive treatment following their diagnosis so the rule evaluates as false and these patients are passed onto the next rule (i.e. 30 patients remain for further processing).

2 If ECZEMA_DAT >= (PPED – 1 month) Reject Next rule

IN OUT REMAINING

- 10 20

Rule 2 takes all patients remaining after Rule 1 (n=30 i.e. the REMAINING number from Rule 1 above) and identifies whether these patients had their Eczema diagnosis within the 1 month period leading up to the payment period end date (the assumption being that these patients may not have had enough time to receive the treatment). If 10 patients had been diagnosed within the last month then the rule evaluates as true for these

patients and they are rejected out of the count so 10 of the patients are now out of the count and processing ends for these patients.

For the remaining 20 patients they did not receive their diagnosis within the last month so the rule evaluates as false and these patients are passed onto the next rule (i.e. 20 patients remain for further processing).

4 If TREATXCON_DAT ≠ Null Reject Select

IN OUT REMAINING

15 5 -

Rule 3 takes all patients remaining after Rule 2 (n=20 i.e. the REMAINING number from Rule 2 above) and identifies whether these patients had a code to indicate that they were contraindicated to treatment X and therefore were not applicable to receive it. If 5 patients were contraindicated then the rule evaluates as true for these patients and they are

rejected out of the count so 5 of the leftover patients are now out of the count and processing ends for these patients.

The remaining 15 patients were not contraindicated to the treatment so the rule evaluates as false. These patients are selected into the count and processing ends for these patients.

There should be no patients remaining once the last rule is evaluated.

End of denominator rules

The final number of patients selected into the denominator is the total number which were selected in each rule.

Out of the total 100 patient in the register 70 + 0 + 15 = 85 selected in 0 + 10 + 5 = 15 rejected out

As the numerator is applied to the patients selected into the denominator, there are 85 patients which the numerator is applied to:

IN OUT START

N/A N/A 85



Numerator

Rule number Rule Action if true Action if false IN OUT REMAINING

1 If TREATX_DAT >= ECZEMA_DAT Select Reject 70 15 -

The first numerator rule takes all patients in denominator (n=85) and identifies whether these patients received Treatment X (TREATX_DAT) after their diagnosis date (ECZEMA_DAT). Note: this is the same as rule 1 from the denominator. If 70 patients had received the treatment on or after their Eczema diagnosis date then the rule

evaluates as true for these patients and they are selected into the count so 70 are in the count and processing ends for these patients.

The remaining 15 patients did not receive treatment following their diagnosis so the rule evaluates as false and these patients are now out of the count and processing ends for these patients.

As there is only one rule in this numerator there should be no patients leftover at the end of this rule.

End of numerator rules

The final number of patients selected into the numerator is the total number which were selected in each rule. As there is only 1 rule in this example this is simply the 70 selected in rule 1.

In the example above the denominator count = 85 and the numerator count = 70.



5. Performing calculations using datesSome of the dates specified for use in the dataset may be used to inform the data extracts or used within the rules which make up each indicator or count.

Where information from a set date is required this means all information from midnight (00:00:00) on that date.

When information up to and including a set date is required, this is taken as meaning up to midnight (23:59:59) on that date. This means that all activity on that date, regardless of time, will be processed.

Where date criteria are specified with intervals of multiples of months or years these should be interpreted as calendar months or calendar years.

A week should be treated as 7 consecutive days.

Where activity is required within a month of a ‘moving date’ (that is a date which may not necessarily fall on the first or last day of a month such as date of birth or a vaccination date) this is usually written as plus or minus 31 days per month, as agreed by NHS England.

Date calculation ExamplesSome examples of how to use these dates in calculations can be seen below:

Date Example Description of Calculation Method

From or Start Dates

>= QSSD This example is looking for information on or after the specified date, therefore this example would look for activity taking place from the start of that day, i.e. on or after the time of midnight (00:00:00) on the QSSD.

To or End Dates

<= ACHV_DAT This example is looking for information up to and including the specified date, therefore this example would look for activity taking place up to the end of that day, i.e. up to and including the time of 23:59:59 on the Achievement Date. This means information effective on the Achievement Date will be included but information on or after midnight (00:00:00) the following day will be excluded.



Patient Age Patients age (years) at ACHV_DAT

This example would look for patient age in full years at the end of the day (23:59:59) on the Achievement Date. E.g. if a patient was born on 30th April 2005 and the Achievement Date is 30th April 2015 then this calculation would return a result of 10 years, regardless of what time of day the patient was born.

If patient age is calculated on a set date but that date is before the patient was born then the intention is that a 0 (zero) value is returned rather than a NULL value or a negative.

Date range in years

PAT_DOB + 5 years If an event is required within a number of years of a ‘moving date’ (that is a date which may not be the end of a calendar month such as date of birth or a vaccination date) this is usually written in years and equates to one calendar year.

In this example the date 5 calendar years following the patient’s date of birth would be returned,

e.g. if PAT_DOB was 1st July 2015 the date returned would be 1st July 2020.

If PAT_DOB was 15th July 2015 the date returned would be 15th July 2020.

If PAT_DOB was 31st July 2015 the date returned would be 31st July 2020.

Regardless of whether the PAT_DOB happens to fall on the first day, the last day or in the middle of a month, the calculation always looks 5 calendar years ahead (in this example).

Date range where the date is a fixed date at the end of a month.

(ACHV_DAT – 1 month)

Where dates are specified in months this refers to one calendar month. As the Achievement Date is usually the last day of a month, this example would calculate the last day of the previous calendar month.

e.g. 1) if Achievement Date was 30th April, this example would return 31st March.

e.g. 2) if Achievement Date was 31st March, this example would return 28th February (or 29th February in a leap year).



Activity within date range where the date is a fixed date at the end of a month.

VACCINE_DAT > (ACHV_DAT – 1 month)

This example would look for activity within or after the 1 month period leading up to the Achievement Date. e.g. if Achievement Date was 30th April, this example would return activity after 23:59:59 on 31st March (i.e. activity from 00:00:00 on 1st April).

This type of calculation could be treated the same as “VACCINE_DAT >= ((ACHV_DAT + 1 day) – 1 month)” where the result would also be activity from 00:00:00 on 1st April.

Date range where reference date is not a fixed date at the end of the month.

(PAT_DOB + 1 month)

This example would calculate the date 1 calendar month after the PAT_DOB. As the PAT_DOB could be at any point during the month, this example would calculate the same day of the next month. e.g. if PAT_DOB was 10th April, this example would return 10th May. If the PAT_DOB does fall on the last day of a month or on a day where there is no corresponding date for the next month (e.g. 29th, 30th and 31st January) then this example would calculate the ‘closest’ valid date (29th, 30th or 31st January + 1 calendar month = 28th Feb or 29th Feb in a leap year).



Activity within date range where reference date is not the end of a month.

ASSESSMENT_DAT > (TREATMENT_DAT – 1 month)

This example would look for activity within (or after) the 1 month period leading up to the TREATMENT_DAT.

e.g. 1) if TREATMENT_DAT was 10th April, this example would return activity after 23:59:59 on 10th March (i.e. activity from 00:00:00 on 11th March).

e.g. 2) if TREATMENT_DAT was 30th April, this example would return activity after 23:59:59 on 31st March (i.e. activity from 00:00:00 on 1st April).

This type of calculation could be treated the same as “ASSESSMENT_DAT >= ((TREATMENT_DAT + 1 day) – 1 month)” where the results would also be 1) activity from 00:00:00 on 11th March and 2) activity from 00:00:00 on 1st April.

If the TREATMENT_DAT does fall on the last day of a month or on a day where there is no corresponding date for the previous month (e.g. 29th, 30th and 31st March) then this example would calculate the ‘closest’ valid date (29th, 30th or 31st March - 1 calendar month = 28th Feb or 29th Feb in a leap year).

Date range in days

VAC_DAT – 31 days If an event is required within a month of a ‘moving date’ (that is a date which may not be the end of a calendar month such as date of birth or a vaccination date) this is usually written as plus or minus 31 days and should be calculated in days. In this example the date 31 days prior to the VAC_DAT date would be returned

e.g. 1) if VAC_DAT was 31st July the date returned would be 30th June.

e.g. 2) if VAC_DAT was 15th May the date returned would be 14th April.

e.g. 3) if VAC_DAT was 1st May the date returned would be 31st March.

Regardless of whether the VAC_DAT happens to fall on the first day, the last day or in the middle of a month, the calculation always looks 31 days backwards (in this example).



Calculations involving dates of birth on or near 29th February

PAT_DOB + 1 year When calculating the age of a patient born on 29th February then in non-leap years the patient’s birthday is considered to be 1st March. If a patient’s date of birth falls on 29th February in a leap year then the corresponding date one year afterwards or one year beforehand is 1st March.

e.g. 1) If PAT_DOB was 29th February 2016 then PAT_DOB + 1 year is 1st March 2017 and PAT_DOB – 1 year is 1st

March 2015.

e.g. 2) If PAT_DOB was 29th February 2016 then PAT_DOB + 4 years is 29th February 2020.

For periods of time which are not multiples of 1 year (e.g. months) then standard rules for dates which are not fixed dates at the end of a month apply.

If PAT_DOB is on 28th February or 1st March and applying a date calculation results in looking forward into a leap year, such as 2016, then the date returned would still be 28th February or 1st March.

e.g. if PAT_DOB was 28th February 2015 then applying PAT_DOB + 1 year would return a date of 28th February 2016.

if PAT_DOB was 1st March 2015 then applying PAT_DOB + 1 year would return a date of 1st March 2016.

If a Data item has a NULL value and is used in the Qualifying Criteria of another Data item then the dependant data item fields will also be NULL as dates cannot be checked against a NULL value.

e.g. if the Dataset Qualifying Criteria is looking for an interventions which took place after a test and the patient has no test date, then it is not possible to check whether an intervention took place after the test. This means the intervention field for this patient will also be NULL.



Calculating date of birth ranges for eligible populationsThe business rules do not routinely specify ranges of dates of birth of eligible patients as they are not required for the extract. As such these date ranges are not provided by NHS Digital unless specifically requested by the customer. Individuals or organisations wishing to independently calculate date ranges for their own can use the logic in the business rules.

For example; In the seasonal influenza v2.0 business rules for the 2016-17 service year, the cohort ‘SFLUCC001’ has the following logic:

This logic uses the value from the field PAT2_AGE outlined in the clinical data extraction criteria table, where PAT2_AGE is defined as the age of the patient at the QSED, as shown in the image below.

The QSED is defined in the qualifying dates table as follows:

So far we understand that the patients age in full years on 31 March 2017 must be 65 or over, therefore patients must have been born at least 65 years before 31 March 2017.

A patient born on 31 March 1952 would have their 65th birthday on 31 March 2017 and therefore PAT2_AGE would be 65 for this patient so the patient would be included in the cohort ‘SFLUCC001’.

A patient born one day earlier on 30 March 1952 would have already turned 65 years old by 31 March 2017 so PAT2_AGE would be 65 and this patient would be included in this cohort.

A patient born one day later on 1 April 1952 would have a PAT2_AGE of 64 so this patient would not be included in this cohort.


http://digital.nhs.uk/media/21722/Seasonal-Flu-v20/pdf/Seasonal_Flu_v2.0.pdf


From this information it can be determined that any patient born on or before 31 March 1952 would meet the criteria of being aged 65 years or over on 31 March 2017 and would therefore be included in the cohort for this service year.

For readers who are confident using Microsoft Excel, the age on certain dates can be calculated using a DATEDIF formula. This formula is written in the following way:

=DATEDIF(<cell containing later of two reference dates e.g. QSED>,<cell containing earlier of two reference dates e.g. DOB>,<format e.g. “y” for years, “m” for months>)

For example:

In the image above the QSED is specified in cell B1 and a date of birth is specified in cell B2. The DATEDIF formula is specified in cell B4 in the following way:

=DATEDIF(B2,B1,”y”)

When the chosen format is “y” then this formula calculates the number of whole calendar years between the two dates in cell B4.

Changing the DOB will allow the user to see what the age of the patient would be on the QSED, for any patient with the specified DOB. By increasing and decreasing this date the user should be able to identify which dates of birth result in the ‘correct’ age and which dates of birth would result in an age which falls outside of the desired criteria.

This example can be amended to compare date of birth against any date of interest by changing the title in cell A1 and date in cell B1.



6. Special SyntaxArraysEach selected patient will usually be represented by a single row in the report, apart from when the operator “ALL” is used in the qualifying criteria of the Clinical data extraction criteria fields. This indicates that an array is required. Rather than specifying a single value such as the earliest or latest, all values are required to be made available so that a combination of records in a sequence can be identified.

The following example shows how an array may be displayed and used within the rules. Any field which requires the return of an array of records will be surrounded by { } e.g. {EXSMOK_DAT}. The qualifying criteria column indicates that ALL records are to be returned.

Example Field Code cluster (if applicable) Qualifying criteria Result

{EXSMOK_DAT} EXSMOK_COD ALL <= ACHV_DATReturn each date when a code from the EXSMOK_COD cluster was recorded in the patient record

{EXSMOK1_DAT} EXSMOK_COD

ALL (>= (EXSMOK_DAT – 24 months)AND < (EXSMOK_DAT – 12 months)AND <= ACHV_DAT)

For each record in the {EXSMOK_DAT} array, return each date when a code from the EXSMOK_COD cluster was recorded in the patient record, where these codes were recorded between 12 and 24 months prior to each {EXSMOK_DAT} record

{EXSMOK2_DAT} EXSMOK_COD

ALL (>= (EXSMOK_DAT – 36 months)AND < (EXSMOK_DAT – 24 months)AND <= ACHV_DAT)

For each combination of {EXSMOK_DAT} and {EXSMOK1_DAT} array records, return each date when a code from the EXSMOK_COD cluster was recorded in the patient record, where these codes were recorded between 24 and 36 months prior to the relevant {EXSMOK_DAT} record

3YEAREX_DAT n/a

Latest array entry in {EXSMOK_DAT} where{EXSMOK1_DAT} index not NullAND {EXSMOK2_DAT} index not Null

Return the latest date from the {EXSMOK_DAT} array where there are values in the EXSMOK_DAT, EXSMOK1_DAT and EXSMOK2_DAT fields. This indicates that there are 3 consecutive years with the presence of an EXSMOK_COD code.



Where fields are set up to return one value for each value in an array, these will be specified in square brackets. Examples can be seen below:


{BP_DAT} BP_COD ALL >= ACHV_DAT

Return each date when a code from the BP_COD cluster was recorded in the patient record up to and including the achievement date

[BPBMI_DAT] BMI_COD

Earliest>= {BP_DAT}AND<= (BP_DAT+ 6 months)

For each record in the {BP_DAT} array, return the first date when a code from the BMI_COD cluster was recorded in the patient record, within 6 months of the associated {BP_DAT} value.(i.e. one BMI date per date in the {BP_DAT} array)



Using the example above if a patient had the following activity in their record…

Code from cluster Date recordedBMI_COD 20/03/2010BP_COD 03/04/2010BP_COD 07/06/2010BMI_COD 15/06/2010BMI_COD 30/06/2010BP_COD 18/09/2010

...then the following results would be returned in the {BP_DAT} array and for the [BPBMI_DAT] field:

{BP_DAT} results [BPBMI_DAT] results03/04/2010 15/06/201007/06/2010 15/06/201018/09/2010 NULL

For fields with square brackets the data is not being returned at patient level like standard fields (i.e. the earliest BMI record per BP recording rather than the earliest BMI record for the patient).

Note: This syntax is new and has not been implemented in any business rules published up to and including the 2016/17 financial year. This may be introduced to future business rules.



Maximum/Minimum Value in TimeframeThe ‘maximum value within a timeframe’ syntax was introduced to business rules in 2015. This type of rule aims to identify the maximum or minimum value or score associated with a set of clinical codes which was recorded during a set timeframe. This is structured as per the example below:


TESTMAX_VAL TEST_CODMaximum score(>=REG_DAT AND <= ACHV_DAT)

The maximum score associated with a code from the TEST_COD cluster which was recorded between Date of patient registration and Achievement date.

NOTE: If the maximum score is achieved more than once during this timeframe, only one record of the score is required to be returned.

In the example above, all scores associated with the codes from the TEST_COD cluster which were recorded between the specified dates (registration date and achievement date) should be interrogated. The highest of those values should be returned. Values recorded outside of the specified timeframes are not included so if the patient previously had a higher score this is not taken into account.

The resulting data item for the TESTMAX_VAL field in the table above should be a single value showing the highest test score recorded during the time period specified in the qualifying criteria. Regardless of how many times this score was achieved during the timeframe specified, the score should only be returned once for this field.



7. Further ResourcesBusiness rules are published on the NHS Digital website in the following location:

http://www.digital.nhs.uk/qofesextractspecs


http://www.digital.nhs.uk/qofesextractspecs

business rules supporting information - digital.nhs.uk€¦ · web viewthese documents contain...

Documents