Page Properties | |||||
---|---|---|---|---|---|
|
|
|
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Introduction
Supports the creation of eMED3 data, its integration into the Patient Record, printing or issuing of MED3 fit note certificates and extraction of data to
The Authority.
The Statement of Fitness for Work (known as a Med 3 form or ‘fit note’) is used throughout Great Britain. Fit notes are issued by doctors, nurses, physiotherapists, occupational therapists and pharmacists for Statutory Sick Pay or Social Security purposes. As a part of a medical consultation a doctor, nurse, physiotherapist, occupational therapist or pharmacist may assess a
Patient’s medical condition to determine its impact on their fitness for work.
The fit note provides return to work advice for the
Patient and their employer and can also be used to support a claim to health related benefits.
The roll out of the computer generated fit note project ‘eMed3’ which was completed in 2014 provided a simple tool for the provision of fit note forms, reducing effort, retaining details and allowing the extraction of fit note data which has been published quarterly since August 2017. Access to the eMED3 has been restricted to doctors but is extended to nurses, physiotherapists, occupational therapists and pharmacists.
This document specifies the requirements in respect of the computer generation, record retention and printing of a fit note and the extraction of data. It ensures the retention of existing processes through consistent implementation across all
Solutions covered by GP IT Futures.
Data extraction and publication
Since 2017,
The Authority has published quarterly anonymous, aggregated data on behalf of the Department for Work and Pensions (DWP) derived from the issue of fit notes saved in the
Electronic Patient Record. The data is extracted from GP IT
Solutions via XML-based eMED3 Activity Files from practices on a weekly basis via Messaging Exchange for Social Care and Health (MESH). The periodic transfer of data will be instigated by the
Supplier’s Solution and automatically submitted to
The Authority.
Requirements
eMED3 Data Recording and Printing | ||
Requirement ID | Requirement Text | Level |
---|
eMED3-01 | Capture and edit New eMED3 data in accordance with eMED3 (Fit Notes) eMED3 Data Entry. |
| ||||||
eMED3-02 | Ability to cancel the transaction at any time during the data entry process. Upon cancelling, Practice User to be informed that by cancelling no record of the eMED3 transaction will be kept and the form, if printed, is to be destroyed. Practice User is to be asked if they wish to continue with cancelling. If NO, the user to be returned to the data entry form. |
|
eMED3-03 |
eMED3-03
Create eMED3 forms (as per eMED3 Template (2022)) |
in an unalterable format (compatible with GP2GP transfer) populated with the eMED3 data recorded in eMED3 (Fit Notes) eMED3-01 |
and as defined in eMED3 Data Items Usage. eMED3 forms only to be created when all mandatory data items as defined in eMED3 (Fit Notes) eMED3 Data Entry |
have been recorded. |
| |||||||
eMED3-04 | Preview unprinted eMED3 forms created as per eMED3 (Fit Notes) eMED3-03. |
|
eMED3-05 |
eMED3-05
Print eMED3 forms created as per eMED3 (Fit Notes) eMED3-03. The form to be printed in the format specified by eMED3 (Fit Notes) eMED3 Template (2022) with data populating the appropriate fields as defined in eMED3 Data Items Usage, |
in the eMED3 (Fit Notes) eMED3 Data Entry table and in eMED3 (Fit Notes) eMED3 Template (2022) with Mappings. For <Patient.title>, |
Suppliers can choose to display the title by striking through the appropriate alternative titles on the form (Mr, Mrs, Ms, Miss) or by simply printing only the relevant title as held on the Patient Record. |
This can include titles other than those listed on the form (e.g. ‘Dr.’, ‘Prof’, ‘Lord’). eMED3 forms only to be printed when all mandatory data items as defined in eMED3 (Fit Notes) eMED3 Data Entry |
have been recorded. |
| ||||||
eMED3-06 | Printed eMED3 |
Statement to contain a 2D Barcode positioned on the form as shown on eMED3 (Fit Notes) eMED3 Template (2022).
For Standards relating to barcode implementation, see: |
| ||||||||
eMED3-07 | If the eMED3 Statement has been printed, but not yet saved to the Patient Record, the Practice User to have the option to amend the data and reprint. An audit of this activity will be captured. |
|
eMED3-08 |
eMED3-08
All eMED3 data and created eMED3 forms to be saved to the |
Patient Record as per eMED3 Data Items Usage. Data can be saved before printing, after printing or (to the user) simultaneously as long as the requirements are met. |
| ||||||
eMED3-09 | Record that eMED3 form was 'issued by hand' (e.g. when retroactively capturing data for a paper-based MED3 form). This function to adhere to requirements eMED3- 01, eMED3-08 and to eMED3 (Fit Notes) eMED3 Data Entry, with the following exceptions:
|
|
|
|
|
eMED3-10 |
eMED3-10
When printing eMED3 forms |
(see eMED3 (Fit Notes) eMED3-05) which are recorded as 'issued by hand', the words “ISSUED BY HAND” to be included overlaid |
in grey scale format and |
in the background on the printed form. |
| |||||||
eMED3-11 | View all saved eMED3 forms and associated data (see eMED3 (Fit Notes) eMED3-01 and eMED3 (Fit Notes) eMED3-03). |
| ||||||
eMED3-12 | Create Duplicate of saved eMED3 form. |
| ||||||
eMED3-13 | Print Duplicate of saved eMED3 form (see eMED3 (Fit Notes) eMED3-03) ensuring the word “DUPLICATE” is included overlaid |
in grey scale format and |
in the background on the printed form. |
| |||||||
eMED3-14 | Duplicates can only be printed of previously issued New statements, i.e. Not statements Issued by Hand or Duplicates previously printed. |
| ||||||
eMED3-15 | For all Duplicate eMED3 forms created, update the Patient |
Record by saving the following data items:
|
|
eMED3-16 |
eMED3-16
Solution to generate a <LinkingID> to be used as a linking identifier allowing DWP to identify all data relating to the same Patient without identifying him or her. The <LinkingID> to be in the form of a DCE UUID and stored with each eMED3 transaction in the Patient’s record. |
| |||||||
eMED3-17 | Solution to ensure that only doctors, nurses, physiotherapists, occupational therapists and pharmacists can capture and edit New eMED3 data and forms (i.e. forms that are not recorded as Issued by hand or Duplicate). |
| ||||||
eMED3-18 | Creation and printing of Duplicate and Issued by hand eMED3 forms to be possible by both doctors, nurses, physiotherapists, occupational therapists and pharmacists as well as GP Practice admin users. |
| ||||||
eMED3-28 | Solution to automatically populate the Name and Profession of the Authorised Health or Care Professional issuing the form; data to be populated in the eMED3 (Fit Notes) eMED3 Template (2022) in the two new data fields. |
| ||||||
eMED3 Data Extraction | ||||||||
eMED3-19 | Ability to extract eMED3 activity data manually and automatically at a specified time. |
| ||||||
eMED3-20 | Format extracted eMED3 activity data into one XML-based eMED3 Activity File adhering to the data elements defined and the record layout indicated in eMED3 Data Items Usage. |
|
eMED3-21 | The structure and enveloping of the extracted content to be consistent with the following eMED3 Activity File XML Schema: |
| ||||||
eMED3-22 | XML-based eMED3 Activity Files will be transferred to |
The Authority on a weekly basis via Messaging Exchange for Social Care and Health (MESH). |
|
eMED3-23 |
eMED3-23
The weekly extraction and transfer to occur every Sunday. |
| |||||||
eMED3-24 | Scheduled extracts to commence from the first Sunday following the eMED3 service going live and weekly thereafter. |
| ||||||
eMED3-25 | Each new submission to be an extract of all eMED3 transaction activity which has occurred since the last extract (unless this is the first extract being taken). Suppliers to not populate extracts with data any older than is covered by the standard extract cycle defined in eMED3 (Fit Notes) eMED3-23. |
| ||||||
eMED3-26 | Each eMED3 Activity File Construction to comprise an envelope and a payload. The payload to be the extracted statistical content as defined in eMED3 (Fit Notes) eMED3 Activity File Payload. Where there are no eMED3 transaction records i.e. a null return as detailed in the schema, an eMED3 Activity File to still be provided. The practice envelope to contain the data itemised in eMED3 (Fit Notes) eMED3 Activity File Envelope. |
| ||||||
eMED3-27 | Data about |
Patients who have registered a Type 1 opt-out (as per National data opt-out programme) will not be included in the eMED3 data extract, unless the |
Patient has withdrawn this at a later date. Opt-out is recorded in the Patient Record currently using the following (Type 1) |
Patient objection code (in SNOMED CT): 827241000000103 - Dissent from secondary use of GP |
Patient identifiable data Withdrawal of this opt-out is recorded on the |
Patient Record currently using the following (Type 1) |
Patient objection code (in SNOMED CT): 827261000000102 - Withdraw dissent from secondary use of GP |
Patient identifiable data The date of the most recent (Type 1) |
Patient objection code i.e. the event data associated with the (Type 1) |
Patient objection code, will be used to determine if data is to be included. |
|
eMED3 Data Entry: Fields and Data
Definition
This table defines the mapping between data items and the form (see eMED3 (Fit Notes) eMED3 Template (2022) with Mappings),
the minimum data to be captured, the rules to be applied to this data
and the preconditions for enabling and disabling the ability to record data on the form:
Field # | Form Field Title | Type | Data Item Saved | Field Contents Displayed | Rule(s) |
---|---|---|---|---|---|
3 | Date of assessment | Date Flag | <AssessmentDate> <AssessmentSixMonthFlag> | Date in dd/month/yyyy format |
This is the date the authorised professional (doctor, nurse, physiotherapist, occupational therapist, or pharmacist) assessed or examined the Patient, or the date he/she considered a report from another healthcare professional.
|
|
|
| ||||
N/A | Admin Term | Code Text Code | <AdminCode> <AdminText> <CodingSystem> | Admin Code Description |
| |||||
4 | Diagnosis | Code Code Text | <DiagCode> <DiagCodeText> <Diag.Printed.Text> | Text from SNOMED CT Dictionary including a coded diagnosis with additional Free Text where applicable |
|
|
| |||||
5 | Not Fit for Work (NFW) | Flag | <NFWFlag> | Tick in the box |
|
| |||||
6 | May Be Fit for work (MFW) | Flag | <MFWFlag> | Tick in the box |
|
| |||||
7, 8 | Comments | Text Text | <NFW.Remarks> Or <MFW.Comments> | Free text as entered | If <NFWFlag> is set:
|
If <MFW.flag> is set:
|
| ||||
9 | Phased return | Flag | <MFWPhaseRtn> | Tick in the box |
|
| |
10 | Altered |
hours Flag | Flag | <MFWAlteredHrs> | Tick in the box |
|
| |
11 | Amended |
duties Flag | Flag | <MFWAmendDuties> | Tick in the box |
|
|
12 |
Adaptations Flag | Flag | <MFWAdaptWorkplace> | Tick in the box |
|
|
13, 14, 15, |
16 | This will be the case for: | Number Number Number Flag Flag | <ValidPeriodDays> <ValidPeriodWeeks> <ValidPeriodMonths> <ValidPeriodIndefinite> <NFWSixMonthFlag> | Days, weeks, months, or “Indefinite Period’ for which statement is valid |
|
|
| |
17, 18 | Or from |
<> TO : <> | Date Date Flag | <ValidPeriodStartDate> <ValidPeriodEndDate> <NFWSixMonthFlag> | Date range for which statement is valid |
|
|
|
| |||||
19 | Follow-up assessment required | Flag Date | <FollowUpAssessment> <Follow.up.date> | Tick in the box |
|
|
|
|
I will/will not need to assess your fitness for work again at the end of this period. | |||||
34, 20 | Calculated Date Time | <UniqueID> <StatementDate <StatementTime> |
|
|
|
|
| |||||
N/A | SAVE or OK | Flag | <PrintedFlag> |
|
|
|
eMED3 Data
Items Usage
The eMED3 Data Items table details all eMED3 data elements, their name, form, and source, and their use as follows:
Display - the data item is displayed for the user while doing the transaction
Saved - the data item is saved to
the Patient Record
Printed - the data item is printed on the statement per eMED3 (Fit Notes) eMED3 Template (2022) with Mappings
Xfr - the data item is transferred to
The Authority
The 'Source' column represents the likely origin of the data:
Sys files - reference data expected to be already held in the Solution, but user selected
Patient Record - data expected to be already held in
the Patient Record
User - new data entered by the user when completing the form
Solution - data generated by the Solution in the completion of the form (either newly generated or using existing reference data)
Where the source is 'Sys files' or 'Patient Record', there is not a requirement for this information to be saved in duplicate to the Patient Record.
eMED3 Data Items
Name | Form | Source | Display | Saved | Printed | Xfr |
---|---|---|---|---|---|---|
<AdminCode> | Sys files | Y | Y | N | Y | |
<AdminText> | Sys files | Y | Y | N | Y | |
<CodingSystem> | Solution | N | Y | N | Y | |
<Patient.title> | As per eMED3 (Fit Notes) eMED3-05 | Patient Record | Y | Y | Y | N |
<Patient.surname> | Patient Record | Y | Y | Y | N | |
<Health.or.Care.Professional-ID> | Solution | N | Y | N | N | |
<AssessmentDate> | dd/mm/yyyy | User | Y | Y | Y | Y |
<AssessmentSixMonthFlag> | flag | User | N | Y | N | Y |
<DiagCode> | Sys files | N | Y | N | Y | |
<DiagCodeText> | Sys files | Y | Y | N | Y | |
<Diag.Printed.Text> | Free text | User | Y | Y | Y | N |
<NFWFlag> | flag | User | Y | Y | Y | Y |
<MFWFlag> | flag | User | Y | Y | Y | Y |
<NFW.Remarks> | Free text | User | Y | Y | Y | N |
<MFW.Comments> | Free text | User | Y | Y | Y | N |
<MFWPhaseRtn> | flag | User | Y | Y | Y | Y |
<MFWAlteredHrs> | flag | User | Y | Y | Y | Y |
<MFWAmendDuties> | flag | User | Y | Y | Y | Y |
<MFWAdaptWorkplace> | flag | User | Y | Y | Y | Y |
<ValidPeriodDays> | nnnn | User | Y | Y | Y | Y |
<ValidPeriodWeeks> | nnn | User | Y | Y | Y | Y |
<ValidPeriodMonths> | nn | User | Y | Y | Y | Y |
<ValidPeriodIndefinite> | flag | User | Y | Y | Y | Y |
<ValidPeriodStartDate> | dd/mm/yyyy | User | Y | Y | Y | Y |
<ValidPeriodEndDate> | dd/mm/yyyy | User | Y | Y | Y | Y |
<NFWSixMonthFlag> | flag | User | N | Y | N | Y |
<FollowUpAssessment> | flag | User | Y | Y | Y | Y |
<Follow.up.date> | dd/mm/yyyy | Solution | N | Y | N | N |
<PrintedFlag> | flag | Solution | N | Y | N | Y |
<DuplicatePrinted> | flag | Solution | N | Y | N | Y |
<StatementDate> | dd/mm/yyyy | Solution | N | Y | Y | Y |
<StatementTime> | hhmmss | Solution | N | Y | N | Y |
<Issuer's.name> | Solution | Y | Y | Y | N | |
<Issuer's.profession> | Solution | Y | Y | Y | N | |
<Practice.name> | Solution | N | N | Y | N | |
<Practice.address1> | Solution | N | N | Y | N | |
<Practice.address2> | Solution | N | N | Y | N | |
<Practice.address3> | Solution | N | N | Y | N | |
<PracticePostCode> | AADD Snn | Solution | N | N | Y | Y |
<PracticeCode> | Solution | N | N | N | Y | |
<Practice.phone.number> | Solution | N | N | Y | N | |
<Patient.first.name> | Patient Record | N | N | Y | N | |
<Patient.second.name> | Patient Record | N | N | Y | N | |
<Patient.Address1> | Patient Record | N | N | Y | N | |
<Patient.Address2> | Patient Record | N | N | Y | N | |
<Patient.Address3> | Patient Record | N | N | Y | N | |
<Patient.DOB> | dd/mm/yyyy | Patient Record | N | N | Y | N |
<Sex> | Patient Record | N | N | N | Y | |
<LinkingID> |
Solution | N | Y | N | Y | ||
<UniqueID> | Solution | N | Y | Y | Y |
eMED3 Activity File Construction
The eMED3 Activity File will comprise an envelope and a payload as defined in eMED3 (Fit Notes) eMED3 Activity File Envelope and eMED3 (Fit Notes) eMED3 Activity Record data items tables.
eMED3 Activity File Envelope
<RecordCount> | A count of the number of records extracted and contained in the payload |
<ExtractReference> | 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 eMED3 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> | The full Post Code of the practice |
<SystemCode> | A code to identify the Solution ( |
Suppliers can choose how to populate this) | |
<VersionRelease> | The Version and Release number of the Solution doing the extract ( |
Suppliers can choose how to populate this) | |
<EmailReceiptAck> | OPTIONAL: nominated email address for receipt acknowledgement by |
The Authority | |
<EmailProcessAck> | OPTIONAL: nominated email address for process acknowledgement |
by The Authority | |
<EmailErrorNotification> | OPTIONAL: nominated email address for any error |
eMED3 Activity File Payload
notification by The Authority |
eMED3 Activity File Payload
The payload will comprise of the data items in the eMED3 (Fit Notes) eMED3 Activity Record data items.
The separately-supplied schema provides
the type for each data item.
eMED3 Activity Record data items
Schema Element Name |
---|
<AdminCode> |
<AdminText> |
<CodingSystem> |
<AssessmentDate> |
<AssessmentSixMonthFlag> |
<DiagCode> |
<DiagCodeText> |
<NFWFlag> |
<MFWFlag> |
<MFWPhaseRtn> |
<MFWAlteredHrs> |
<MFWAmendDuties> |
<MFWAdaptWorkplace> |
<ValidPeriodDays> |
<ValidPeriodWeeks> |
<ValidPeriodMonths> |
<ValidPeriodIndefinite> |
<ValidPeriodStartDate> |
<ValidPeriodEndDate> |
<NFWSixMonthFlag> |
<FollowUpAssessment> |
<PrintedFlag> |
<DuplicatePrinted> |
<StatementDateTime> |
<Sex> |
<LinkingID> |
<UniqueID> |
eMED3 Template (2022)
View file | ||
---|---|---|
|
eMED3 Template (2022) with Mappings
This template defines the mappings between the printed form and the eMED3 data items. This can be used with the eMED3 Data Entry: Fields and Data Definition table to establish where data recorded is to be printed on the form.
shows this for all data items.
View file | ||
---|---|---|
|
eMED3 Template Mappings - all printed data items
Expand | ||
---|---|---|
|
#
Name
1
|
|
3
|
|
|
|
4
|
5
|
6
|
|
|
|
10
|
11
|
|
|
|
15
|
16
|
17
|
|
|
|
18
|
18d
|
18m
|
18y
|
|
20
|
20d
|
20m
|
|
|
|
23
|
24
|
25
|
26
|
|
28
|
29
|
30
|
31
|
32
|
|
33d
-
|
|
|
|
Capability
Applicable
Capabilities
All
Supplier Solutions will need to meet this Standard if they are delivering the Consultation Management - GP Capability.
Roadmap
Dependencies
Creating a compliant implementation requires implementing the following dependent interface Standards:
Excerpt | ||
---|---|---|
| ||
Roadmap
Items on the Roadmap which impact or relate to this Standard |
---|
Suppliers will not be assessed or assured on these Roadmap Items as part of Onboarding
|
|