Skip to main content

Guide to NHAIS/GP links documentation

Documentation overview

  • 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. 

Changes since GP links specification

This section describes the messages with known issues or messages known to have been deprecated since the original requirements specification was published. In addition, it highlights several additional areas where the “business has moved on” since the original publication of the GP Links documentation (but where the documentation has not been updated to reflect this). 

Message transport

HealthLink (X400) has been replaced by MESH as the delivery mechanism. No functional change has been identified (yet) following the move from X400 messaging to MESH.  

Each NHAIS server has an allocated MESH mailbox. 

Obsolete requirements

  • All Items of Service transactions are obsolete – amendment to 1.1. The ONLY requirement is for the GP system to integrate with the NHAIS systems for the exchange of patient registration/demographics data. 
  • MRF and MRS (Medical Records) transactions are obsolete in England– amendment to 2.2.5. i.e. the MRFR and MRS transactions detailed in sections 3.17 and 3.18 will not be received from an English NHAIS system. 
  • Close of quarter notification (HA->GP) (section 2.26, 2.27, 2.28 and 3.20) can be treated as a COULD. Note that – the NHAIS systems will send a Close Quarter notification transaction to all linked GP Practice systems. This is merely stating that it is acceptable for the GP system to ignore the receipt of such transactions. 
  • Reconciliation transactions can also be treated as a COULD. i.e. it is acceptable for the GP system to not support the sending of Download transactions to NHAIS (section 3.10) and the receipt of corresponding Upload transactions from NHAIS (section 3.19). 
  • References to ‘RPP Mileage’, ‘Blocked Route/Special District Marker’ and ‘Walking Units’ are obsolete and there is no requirement for these fields/data items to be supported or maintained within a GP System. They are still however in the EDI Message Design.  
  • All references to Manual Registration should be ignored. Manual Registration was applicable during the transition from paper-based registration to electronic registration using the NHAIS. This transition is now complete therefore it is assumed that in all cases, GP systems will make use of NHAIS electronic registration transactions only. 

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. 

Responsible HA 

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.  

Supported messages

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)

 

Related pages

  1. internal

    NHAIS developer document library

    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.

Last edited: 9 May 2019 12:32 pm