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.
2.8	Core Technical Team	22/03/2007	Moved XML Example files to a subdirectory within the Examples directory

 

 

1    Overview

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:

 

• GP summary

 

All clinical statements carried within messages shall be classified by one and only one CRE category

1.1    Error Correction

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.

1.1.1    Message update of incorrect information

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:

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

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

3. This mechanism should not be used for withdrawing information when a patient has expressed their dissent to NCRS record sharing.

1.1.2    Message Replacement

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:

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

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

3. 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)

 

2    Use Cases

2.1    GP Summary Use Cases

The use case diagrams supporting the GP Summary domain can be viewed by following the link below :

GP Summary Use Case Diagrams v2.0

 

3    Storyboards

3.1    GP Summary Initial upload to PSIS

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.

3.2    GP Summary Update to PSIS

 

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.

 

 

4    Application Roles

The applications involved in the GP Summary processes play specific roles.  These, along with the interactions associated with each role, are identified below.

 

4.1     GP Summary sending system REPC_AR150004UK01

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

 

4.2     GP Summary receiving system ( PSIS ) REPC_AR150005UK01

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

 

 

5    Trigger Events

5.1     Initial Communication of GP Summary ( text ) to PSIS - REPC_TE150004UK01

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

5.2     Update of GP Summary to PSIS - REPC_TE150005UK01

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

5.3     GP Summary withdrawal - REPC_TE150006UK01

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

 

 

6    Interaction Diagrams

6.1    GP Summary Interactions

 

7    Interactions

7.1     Initial GP Summary ( text ) - REPC_IN150015UK05

The GP Summary communicates an initial summary of the patient record held on a GP system to PSIS.

 

Sending Role	GP Summary sending system	REPC_AR150004UK01
Receiving Role	PSIS	REPC_AR150005UK01
Trigger Event	Initial Communication of GP Summary ( text )	REPC_TE150004UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	GP Summary ( text )	REPC_MT150002UK05

 

 

Receiver Responsibilities

Reason	Interaction
Application Acknowledgement	Application Acknowledgement MCCI_IN010000UK13

 

 

7.2     GP Summary - REPC_IN150016UK05

The GP Summary communicates an update summary of the patient record held on a GP system to PSIS.

 

Sending Role	GP Summary sending system	REPC_AR150004UK01
Receiving Role	PSIS	REPC_AR150005UK01
Trigger Event	Update of GP Summary to PSIS	REPC_TE150005UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	GP Summary	REPC_MT150007UK05

 

 

Receiver Responsibilities

Reason	Interaction
Application Acknowledgement	Application Acknowledgement MCCI_IN010000UK13

 

 

7.3     Withdraw Initial GP Summary ( text ) - REPC_IN150017UK02

Withdrawal of GP Summary ( text ).

 

Sending Role	GP Summary sending system	REPC_AR150004UK01
Receiving Role	PSIS	REPC_AR150005UK01
Trigger Event	GP Summary withdrawal	REPC_TE150006UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Generic withdrawal message	UKCI_MT000001UK02

 

 

Receiver Responsibilities

Reason	Interaction
Application Acknowledgement	Application Acknowledgement MCCI_IN010000UK13

 

7.4     Withdraw GP Summary - REPC_IN150018UK02

Withdrawal of GP Summary.

 

Sending Role	GP Summary sending system	REPC_AR150004UK01
Receiving Role	PSIS	REPC_AR150005UK01
Trigger Event	GP Summary withdrawal	REPC_TE150006UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Generic withdrawal message	UKCI_MT000001UK02

 

 

Receiver Responsibilities

Reason	Interaction
Application Acknowledgement	Application Acknowledgement MCCI_IN010000UK13

 

 

8    Message Definitions

8.1     GP Summary ( text ) - REPC_MT150002UK05

The GP Summary communicates a summary of the "patient's" record held on the GP system to PSIS.

 

       

 

8.1.1    Scenario : A GP Practice does its GP Summary initial upload to PSIS.

GP Summary ( text )   

 

GP Summary ( text ) no data found   

8.2     GP Summary - REPC_MT150007UK05

The GP Summary communicates a summary of the patient's record held on the GP system to PSIS.

 

       

 

8.2.1    Scenario : A GP Practice does a GP Summary update to PSIS.

GP Summary update   

 

GP Summary no data found   

 

GP Summary patient refused consent for upload   

 

---

9    Glossary of Terms

PSIS	Personal Spine Information Service.
ETP	Electronic transfer of Prescriptions.

 

---

10    Changes for version 2.8

10.1    Changes to Example Messages.

The XML Example files have been moved to a subdirectory within the Examples directory.

11    Changes for version 2.7

11.1    Changes to IM content

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)

11.2    Changes to tabular views

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)

 

11.3    Changes to examples

The presentation text within the example messages have been amended as a result of ongoing clinical reviews.

 

11.4    Other changes that affect this domain

The schema for Finding CMET has had the incorrect Systolic Snomed code corrected from 271649005 to 271649006 ( Bugzilla ref 20011 )

 

11.5    Change requests for this release

 

 CR-0738