Skip to main content

Fit notes issued by GP practices in England - Extract specification

Information on the data extraction criteria for the fit notes issued by GP practices statistical publication. 


This specification provides detail on what has been extracted from GP systems. It is expected to be of interest to users who are familiar with NHS primary care systems.

Dataset specification

An electronic fit note on a GP system is known as a Med3 file.

The extracted Med3 activity file comprises an envelope and a payload.  The following details the data items that are included in the practice envelope and each Med3 activity record.

Data items 

Data items in the extract envelope file for each practice
RecordCount A count of the number of records extracted and contained in the payload



A GUID assigned by the supplier on extraction and stored for future reference; used for manual diagnostic transaction identification/correlation
ExtractDateTime The date and time of Med3 activity extraction
SubmissionDateTime  It is expected that transmission will occur immediately after extraction so this will be the same timestamp as above
PracticeCode The practice ODS code
PracticePostCode OPTIONAL: The full post code of the practice
SystemCode A code to identify the GPSOC system of the PMS (suppliers can choose how to populate this)
VersionRelease The Version and Release number of the PMS doing the extract (suppliers can choose how to populate this)
EmailReceiptAck OPTIONAL: nominated email address for receipt acknowledgement by NHS Digital
EmailProcessAck OPTIONAL: nominated email address for process acknowledgement by NHS Digital
EmailErrorNotification OPTIONAL: nominated email address for any error notification by NHS Digital
Data items included in the extract payload and are described as used by the GP at the GP practice

Data item 



Date assessed by the Clinician.

This is the date the clinician assessed/examined the patient or considered a report from another healthcare professional.  It can be the same date the statement is issued (which is normal and should be the default date displayed at the outset of the transaction), or it can be any date preceding the issued date.  It cannot be a future date.  There is no limit on how far in the past the date can be.  However, if the clinician inputs a date which is 26 weeks or more before the day of issue, (the current date), a dialogue box should prompt the clinician to confirm that the correct assessment Date has been entered.  If confirmed, the six-month flag should be set and if not confirmed allow for re-entry of the assessment date



The text of appropriate Admin Code for the NEW statement being issued. Either of the 2 sets of text depends on how the supplier chooses to implement users’ navigation to Med3 functions.  That is, at this point it can be chosen from a drop down list of the 2 NEW codes (NFW and MFW), or it can be simply the text “NEW Statement” with the NFW/MFW choice determined by what the user ticks in steps 4/5.  


This field is the principal diagnosis causing the statement to be issued, with user control over the text actually printed on the statement.




Two tick-boxes where ONE AND ONLY ONE MUST be ticked.





If NFW.flag is set then these 4 tick boxes should be disabled and displayed in background grey-scale.

If MFW.flag is set, these 4 tick-boxes enabled and are optional.  Any combination of the 4 boxes may be ticked, including all and none.








These steps enable the clinician to define the period of time for which the statement is valid, either using days/weeks/months or specifying a start and end date.

The anchor date is the Date of Assessment for both modes.  Suppliers must comply with current standards regarding the handling of dates as specified in the CUI (Common User Interface).

These fields are OPTIONAL with the exception of NFW.Six.Month.Flag

Ticked if a follow-up assessment is required at the end of the period.  The date is entered or auto-calculated 


Med3.Unique.ID is calculated



Med3.Statement.Date and Med3.Statement.Time are set automatically, but can be amended by clinician.
Med3.IssuerProfession Profession of the person issuing the fit note
Med3.Printed.flag or Med3.Duplicate.Printed Signifies end of fit note process


The linking ID is to be machine-generated and stored with the Med3 transaction in the patient’s record and included in the Med3 transaction data transferred to NHS England. The linking ID should be in the form of a DCE UUID assigned to each patient within the record 

The fit note functionality in a GP practice system provides additional data fields for free text and patient information. These were considered too disclosive for the extract and are not included. 



  • File: extract from supplier, contains many envelopes;
  • Envelope: extract from a given GP Practice, contains the individual fit notes and header information;
  • Fit note: individual Med3 extract.

File level validations

  • If the fit note file does not correspond structurally to the schema then reject whole file
  • If the GP practice code is not valid as per DSS corporate reference data then reject whole file
  • Check record count per file is correct. If incorrect then the file should still be processed but flagged as a data quality issue to investigate.

Fit note level validations

  • The ValidPeriodDays value (if supplied) must be no more than 4 digits in length and an integer, otherwise reject individual Med3.
  • The ValidPeriodWeeks value (if supplied) must be no more than 3 digits in length and an integer, otherwise reject individual Med3.
  • The ValidPeriodMonths value (if supplied) must be no more than 2 digits in length and an integer, otherwise reject individual Med3.
  • The ValidPeriodIndefinite value (if supplied) must say 'INDEFINITE' (not case sensitive), otherwise reject individual Med3.
  • If the Extract Date is before the Statement Date Time then reject individual Med3.
  • If the Statement Date is before December 2014 then reject individual Med3.
  • The data type for a given field must conform to the expected data type, otherwise reject individual Med3.
  • The Med3 does not have 
    • ValidPeriodStartDate OR AssessmentDate

AND at least one of the following:

  • ValidPeriodDays
  • ValidPeriodWeeks
  • ValidPeriodMonths
  • ValidPeriodIndefinite 
  • ValidPeriodEndDate

then reject individual eMed3.

  • A single flag must be given for MFW or NFW, if both or neither are selected the eMed3 should be rejected.
  • Issuer profession must be one of the following (not case sensitive): Doctor, Nurse, Physiotherapist, Occupational Therapist, Pharmacist. Otherwise reject individual eMed3.
  • Sex field must contain one of the following: 0, 1, 2, 9. Otherwise reject individual eMed3.


File level deduplication

It is recognised that practices change GP practice systems from time to time. During migration from the old to the new system, it is possible that systems are run in parallel, and data can exist in both systems and therefore be extracted by two (or more) different suppliers for the same practice code.

If the files contain eMed3's with duplicated Unique Id's, these are flagged as duplicates and are not processed. If the files contain some duplicated eMed3's and some unique eMed3's, the unique eMed3's are processed.

The quality report indicates on a weekly basis how many multiple submissions have been received for a given practice code.

If two files are received with the same Extract Reference then the whole file and all eMed3's within are rejected.

Fit note level deduplication

The UniqueID of a new eMed3 must not be a duplicate of an existing eMed3. The duplicate check searches all historical data to ensue that none of the new entries are duplicates of existing eMed3's. Any duplicates identified are flagged in an archive table and not processed further.

Duplicate eMed3s most commonly occur when a duplicate fit note is printed for a patient. These should contain a 'duplicate print' flag.

Derivations and calculations

Duration calculation 

  • If no ValidPeriodStartDate is supplied, or it = 01-01-1900, then AssessmentDate is used in it's place for the DurationDays calculation.
  • IF ValidPeriodIndefinite is supplied THEN DurationDays = 0
  • IF ValidPeriodIndefinite is not supplied AND (ValidPeriodDays + (days in ValidPeriodWeeks) + (days in ValidPeriodMonths)) >= (ValidPeriodEndDate – ValidPeriodStartDate) THEN DurationDays = (ValidPeriodDays + (days in ValidPeriodWeeks) + (days in ValidPeriodMonths))
  • IF ValidPeriodIndefinite is not supplied AND (ValidPeriodEndDate – ValidPeriodStartDate) >= (ValidPeriodDays + (days in ValidPeriodWeeks) + (days in ValidPeriodMonths)) THEN DurationDays = (ValidPeriodEndDate – ValidPeriodStartDate)
  • ELSE DurationDays = NULL - no else required as prior Validations ensures that this calculation is possible.

Code mapping to ICD10

Definition: fit note diagnostic codes need to be mapped to ICD10 and aggregated to a chapter level, and up sub-chapter codes. The extracted data includes diagnostic codes in the practice’s coding system. These are read clinical codes version 2 (Read) and clinical terms version 3 (CTV3) or SNOMED which is in the process of replacing Read and CTV3.

Business rule: These codes are mapped to the ICD10 coding system, using NHS England reference mapping tools.

Standards: NHS England reference mapping tools. Codes are updated by NHS England on a 6 monthly basis, and suppliers are expected to update their systems to incorporate new codes. Historical codes are not deleted.

NIS-retired codes: If data contains retired codes, as is likely for the historical data, where possible these will be mapped to the relevant ICD10 chapter even if mapping at sub-chapter level is not possible.

Linked fit notes

Definition: Fit notes that are linked with the same linking ID are considered to be linked fit notes.

Assumption:  The same linking ID will be present for consecutive, as well as non-consecutive, fit notes.

Business rule: For calculating duration of a linked episode, two or more fit notes will be considered linked if:

  • They have the same linking ID.
  • They are consecutive, that is,
    • the statement date of the newer fit note is the within the period of the previous fit note, or
    • the statement date is the same as the end of the previous fit note, or
    • the statement date falls within 7 days of the end of the previous fit note.

If two fit notes have the same linking ID, but are more than 7 days apart, (end date and statement date) they will be considered separate episodes.

Where a patient moves practices, the linking ID will follow the patient if the fit note data is transmitted successfully by GP2GP record transfer.  In these cases, display of linked fit note data will take the GP Practice ID from the most recent individual Med3 in the episode.

In a series of linked fit notes, the gender and diagnosis code is taken from the first fit note in the series. The GP practice code is taken from the last fit note.

Last edited: 30 March 2023 11:17 am