GP Summary Implementation Manual | ||||
Programme |
NPFIT |
DOCUMENT NUMBER | ||
Sub-Prog/Project |
Comms & Messaging |
NPFIT-FNT-TO-DPM-0602 | ||
Prog. Director |
Paul Jones | |||
Sub-Prog/Proj Mgr |
Kenneth Lunn | |||
Author |
C&M Development Team |
Version No. |
2.6 | |
NPO/PSO Contact |
Richard Kavanagh |
Status |
Issued |
Contents
Change History
In Version | Author | Date | Amendment Details |
2.5 | Core Technical Team | 11/07/2006 | The whole of this domain has been remodelled using a CMET approach for CRE types. |
2.6 | Core Technical Team | 07/08/2006 | Change to messages after meeting with suppliers - details listed in change history |
2.7 | Core Technical Team | 30/11/2006 | Fixes for Bugzilla issues 20080, |
Phase 1 of Provision of Care focuses on discharge and shared care processes and the associated communications between primary care and secondary care. The message definitions within this document support the following Care communications:
All clinical statements carried within messages shall be classified by one and only one CRE category
If a message is sent in error, then the sending system should send a ‘Notify Message Withdrawal’ message. For example, this withdrawal message would be used if a message was sent with an incorrect patient NHS Number.
If a message was sent and subsequently was found to have incorrect
information then the initial message should be withdrawn using ‘Notify
Message Withdrawal, and replaced with a new message using message
replacement. The status of the withdrawn Event will be set to withdrawn.
Note:
This means if a message had one piece of information which was incorrect then all of the message should be withdrawn and replaced with a new message which corrects the error.
This should not be used to progress data that was true at the time of sending but to replace only information which was never true.
This mechanism should not be used for withdrawing information when a patient has expressed their dissent to NCRS record sharing.
If a new message contains information that completely supersedes a previous
message, but the existing information was correct, then the new message
should be sent as a complete message replacement. The status of the replaced
Event will be set to replaced.
Note:
This means if a message had one piece of information which was incorrect then all of the message should be withdrawn and replaced with a new message which corrects the error.
Note that if it is subsequently found that the replaced information was actually incorrect, then a ‘Notify Message Withdrawal’ message must be sent to withdraw the replaced message. The status of the event carried by the withdrawn message will be set to withdrawn.
For GP Summary messages if there is an existing GP summary (text) or GP summary message on PSIS then that message MUST be replaced by the new message being sent. This will be done by referencing the id of the existing message on PSIS in the message reference act of the new message being sent.
The following messages in this domain may be withdrawn using the generic 'Notify withdrawal message'.
GP Summary |
GP Summary (text) |
The use case diagrams supporting the GP Summary domain can be viewed by following the link below :
GP Summary Use Case Diagrams v2.0
RoseTree GP Practice patient record system has passed the necessary data quality checks, filtered the correct data from Peter Parker's patient record and been scheduled to do its GP Summary upload. The system has been configured to automatically send GP summaries. Peter Parker’s summary is next in the queue of summaries on the GP system and his GP Summary is sent by the GP practice system to PSIS as an initial GP summary message.
Peter Parker visits Dr Franks at RoseTree Practice
complaining of a rash which has developed after he started taking
antibiotics prescribed the day before by another doctor at the practice. Dr
Franks diagnoses a possible allergy to Penicillin. After telling Peter not
to take any more of the antibiotics, he prescribes some new antibiotics
which do not contain any Penicillin.
He advises Peter that this information should be updated as an allergy on
Peter's record on PSIS. Peter agrees that this is a good idea and agrees to the
information being sent. Dr Franks updates Peter's record with the allergy
and new medication details on the GP system and the system asks if he wants
to update the patient GP summary on PSIS. Dr Franks confirms he does and the
system sends an updated GP summary message which contains the previous GP Summary
with the new medication and allergy information added.
The applications involved in the GP Summary processes play specific roles. These, along with the interactions associated with each role, are identified below.
The GP Summary sending system is responsible for initiating the following Provision of Care interactions: Upload of GP Summary to PSIS.
GP Summary sending system interactions
The GP Summary receiving system ( PSIS ) is responsible for storing the GP summary and make available for future use.
GP Summary receiving system ( PSIS ) interactions
The trigger event for the initial GP Summary upload is that the GP practice system has passed data quality checks and has filtered the correct data from the patient's record and has been scheduled to do its GP Summary upload. This may be a bulk process on the sending system in that summaries for all the permanently registered patient's will have initial summaries created. However, each patient's summary is sent as a distinct, separate interaction . Note :- no message batching process is used for GP Summary.
The GP Summary business process model and relevant documentation included in this release of the MIM should be referred to for further information concerning when an initial GP Summary should be sent.
Structured Name | Initial Communication of GP Summary (text) to PSIS |
Type | State Transition |
State Transition | GP Summary text message is sent to PSIS |
The trigger event for the Update of the GP Summary to PSIS is that information has been made available to the GP which requires a change to any GP Summary data held on PSIS.
Note there may not be any data held in an existing "Initial GP Summary" or "GP Summary" on PSIS, in this case the GP Summary will populate PSIS."
For full details on events which will require an update GP summary message
refer to the GP Summary business process model and relevant documentation
included in this release of the MIM.
Structured Name | Update of GP Summary to PSIS |
Type | State Transition |
State Transition | GP Summary message is sent to PSIS |
For the GP Summary message to be withdrawn, the trigger event is the realisation that the GP Summary message was in error, in that it contained an error and should never have been sent.
Structured Name | GP Summary Message withdrawal |
Type | State Transition |
State Transition | GP Summary message is withdrawn |
The GP Summary communicates an initial summary of the patient record held on a GP system to PSIS.
Sending Role | GP Summary sending system | |
Receiving Role | PSIS | |
Trigger Event | Initial Communication of GP Summary ( text ) | |
Transmission Wrapper | Send Message Payload | |
Control Act Wrapper | Control Act | |
Message Type | GP Summary ( text ) |
Receiver Responsibilities
Reason | Interaction |
Application Acknowledgement | Application Acknowledgement |
The GP Summary communicates an update summary of the patient record held on a GP system to PSIS.
Sending Role | GP Summary sending system | |
Receiving Role | PSIS | |
Trigger Event | Update of GP Summary to PSIS | |
Transmission Wrapper | Send Message Payload | |
Control Act Wrapper | Control Act | |
Message Type | GP Summary |
Receiver Responsibilities
Reason | Interaction |
Application Acknowledgement | Application Acknowledgement |
Withdrawal of GP Summary ( text ).
Sending Role | GP Summary sending system | |
Receiving Role | PSIS | |
Trigger Event | GP Summary withdrawal | |
Transmission Wrapper | Send Message Payload | |
Control Act Wrapper | Control Act | |
Message Type | Generic withdrawal message |
Receiver Responsibilities
Reason |
Interaction |
Application Acknowledgement |
Application Acknowledgement |
Withdrawal of GP Summary.
Sending Role | GP Summary sending system | |
Receiving Role | PSIS | |
Trigger Event | GP Summary withdrawal | |
Transmission Wrapper | Send Message Payload | |
Control Act Wrapper | Control Act | |
Message Type | Generic withdrawal message |
Receiver Responsibilities
Reason | Interaction |
Application Acknowledgement | Application Acknowledgement |
The GP Summary communicates a summary of the "patient's" record held on the GP system to PSIS.
GP Summary ( text ) no data found
The GP Summary communicates a summary of the patient's record held on the GP system to PSIS.
GP Summary patient refused consent for upload
PSIS | Personal Spine Information Service. |
ETP | Electronic transfer of Prescriptions. |
The wording in section 5.2 has been changed
from - "Note there may not be any data on PSIS to update, in this case the update message will upload data to PSIS."
to - Note there may not be any data held in an existing "Initial GP Summary" or "GP Summary" on PSIS, in this case the GP Summary will populate PSIS." (Bugzilla ref 20019)
The description of the replacement message reference has been clarified with regards to indicating that PSIS Event and Message UUID are identical for GP Summary. (Bugzilla ref 20018)
The presentation text within the example messages have been amended as a result of ongoing clinical reviews.
The schema for Finding CMET has had the incorrect Systolic Snomed code corrected from 271649005 to 271649006 ( Bugzilla ref 20011 )