- Contents.doc v1 provides contents of chapters 1, 2 and 3
- Chapter 2; the section detailing the ‘System Requirements’ is good place to start.
- Chapter 2.2.5; ‘Transaction Types’ (Page 5) defines the NHAIS transaction types
- Then Chapter 3:
- “Incoming” transactions are HA → GP
- “Outgoing” transactions are GP → HA
- Chapter 4; provides a range of miscellaneous requirements around how the GP system should support GP Links with an NHAIS system.
- Finally, a range of appendices (A to K) provide a range of additional information in support of the body of requirements documented within chapters 3 and 4. GP system suppliers new to EDI messaging will find Appendix J especially useful as it contains a range of example GP Links messages in EDI format.
Miscellaneous other changes/requirements
It should be noted that a detailed review of the GP links specification has not been undertaken to check all aspects of the original specification and whether these are still relevant. However, below is a list of known features/requirements within the specification that should be noted by any new GP system supplier.
System link to NHAIS
Throughout the documentation, there are references to whether the GP system is “linked” to an NHAIS system (or not) – i.e. whether the GP system is actively supporting GP links. It is assumed that, if a new GP system is going to support GP Links interaction with NHAIS, this solution will be robust enough to not require a contingency for the link not being operational. Therefore, there are no requirements for a GP system that will support GP links being capable of producing “paper equivalents” of GP links transactions.
Registration type algorithm
Section 3.3.3.a includes an algorithm for determining the Registration Type to include within an Acceptance transaction. Whilst this algorithm is fundamentally correct, it should be noted that:
- Few patients will not have an FP4 (medical card). This part of the algorithm is effectively asking the patient whether they are currently or were last registered with another GP Practice within the UK.
- It is unknown whether patients are still given an FP13 as part of being discharged from the Armed Services. This part of the algorithm is effectively asking whether the patient has just been discharged from the Armed Services.
- New-born babies are no longer given an FP58 “pink baby card”. This part of the algorithm is effectively asking whether the patient is a new-born (under one year of age), born in the UK, with an NHS Number (allocated at the point of birth) who has not been previously-registered with another GP Practice.
Throughout the documentation, there are references to Patient’s Responsible HA. This equates to the NHAIS Cipher of the NHAIS system on which the patient should be registered.
NHS number formats
Throughout the documentation (including appendix F), there are various references to different NHS number formats. There is now only one NHS number format – 10 numeric values. There is no requirement for the GP system to support old format NHS Numbers and (temporary or query) numbers will no longer be sent from NHAIS systems to GP practices over GP links.
GP partnerships/GP practices
Throughout the documentation, there are various references to GP Partnerships/GP Practices. It is assumed now that the GP system will have a “link” to an NHAIS system for each different GP Practice (determined by National Practice Code) that it supports.
GP local codes
Throughout the documentation, there are references to GPs with GP local codes. It is recommended that, for the purposes of GP links, it is assumed that all the patients registered with a GP Practice are registered with a single, generic “pooled list” GP (i.e. patients are not registered with different GPs) that corresponds to the Practice as a whole. In addition, it is recommended that this GP local code is the same as the national practice code for the practice (i.e. one alpha followed by 5 numeric values).
Chapter 4 changes
Chapter 4 contains a set of additional requirements around the GP system and GP links. It should be noted that:
- Section 4.2 relates to Medical Records and Medical Record transactions. As indicated above, this can be ignored if the GP system is to interact with an English NHAIS system.
- Section 4.3.1 can be ignored if the GP system is not going to support the Download and Upload transactions that support GP Links reconciliations.
- Section 4.3.7 discusses a table of valid GP local codes. As indicated above, it is recommended that the GP system just uses a single GP local code for all the patients registered with the one GP Practice that the practice system is supporting.
- Section 4.3.14 can be ignored as NHAIS systems no longer generate (query/temporary) NHS Numbers.
- Section 4.3.18 can be ignored in that there is no requirement for the detail of historic transactions to now be archived.
- Section 4.3.21 can be ignored as MRS transactions will no longer be generated by English NHAIS systems.
- Section 4.3.24 can be ignored as MRFR transactions will no longer be generated by English NHAIS systems.
- Section 4.3.25 can be ignored if the GP system is not going to support the Download and Upload transactions that support GP Links reconciliations.
Appendix A changes
Appendix A includes a set of archive audit record layouts. Whilst these can now be considered to NOT be mandatory, it is recommended that the GP system does maintain a complete audit of all GP Links transactions sent to NHAIS systems (and what happens to them) and a complete audit of all GP Links transactions received from NHAIS systems (and what happens to them). These can be in any format. In addition, there is no longer a requirement for a quarterly archive of GP Links transaction information. It is recommended that audit files of GP Links transactions are retained indefinitely within the GP system.
Appendix B changes
There is no requirement for GP systems to support Appendix B. That said, GP Practices themselves may wish for their GP system to include the equivalent of a Quarterly Capitation Report.
Appendix C - G
- Appendix C (as itself indicates) can be ignored.
- Appendix D includes a number of Ciphers that are now no longer in use. So, the following Ciphers can now be ignored – BOL, BUY, GMH, GWY, HAL, IW, MGA, OLD, POS, SOS and TYN. In addition, since this specification was written, a new “DMS” NHAIS system has been created (for the registration of Armed Services personnel) and so DMS is now a valid Cipher.
- Appendix E. As indicated above, this appendix can be ignored.
- Appendix F. As indicated above, there is now only one NHS Number format – 10 numeric values.
- Appendix G. Whilst a small number of the listed deduction codes are now no longer used, it is recommended that the GP system support the receipt of this full set of codes.
GP Links to HA
- “ACG” – Acceptance transaction
- “AMG” – Amendment transaction
- “REG” – Removal (Out of Area) transaction
- “DER” – Deduction Request transaction
HA to GP Links
- “AMF” – Amendment transaction
- “DEF” – Deduction transaction
- “APF” – Approval transaction
- “REF” – Rejection (Wrong HA) transaction
- “FPN” – FP69 Prior Notification transaction – Section 3.21
- “FFR” – FP69 Flag Removal transaction
- “DRR” – Deduction Request Rejection transaction
- Close Quarter Notification (chapter 3.20, Chapter 3 page 154) (may be considered optional)
This information aims to help GP IT suppliers to understand NHAIS GP links requirements, and may be useful to architects and designers who wish to understand which messages have been deprecated since the original requirements were issued.