Contents

 

 

 

Change History

In Version	Author	Date	Amendment Details
1.0	Core Technical Team	13/02/2004	First release
1.1	Core Technical Team	25/03/2004	Change request DACM-NS-39: Changes and corrections for P1R1, mainly comprising documentation changes relating to constraints on data not supported by the PDS in P1R1. Details of changes made are given in section 10.
2.0	Core Technical Team	10/05/2004	Version to support P1R2
2.1	Core Technical Team	25/06/2004	Change request DPM-0079.01. Details of changes made are given in section 10.
2.2	Core Technical Team	16/07/2004	Change request DPM-0192.01. Details of changes made are given in section 10.
2.3	Core Technical Team	20/08/2004	Fixed hyperlinks.
2.4	Core Technical Team	26/08/2004	Includes new generic Control Act Wrapper, new SDS OIDs and updated Agent SDS CMETs.
2.5	Core Technical Team	29/10/2004	Change requests MIM-CR-0034, 0053, 0095, 0116, 0059 and 0103. Details of changes made are given in section 10.
2.6	Core Technical Team	06/12/2004	Change requests MIM-CR-0208, 0270 and 0280. Details of changes made are given in section 9. Section 8 (Interaction Index) from previous MIM structure has been removed.
2.7	Core Technical Team	31/03/2005	Change requests MIM-CR-0239, 0240, 0242, 0275, 0299, 0419, 0428 and 0454. Details of changes made are given in section 9.
2.8	Core Technical Team	05/08/2005	Change requests MIM-CR-0547 and 0548. Details of changes made are given in section 9.
3.0	Core Technical Team	30/09/2005	Change requests MIM-CR-0626, 0627, 0630 and 0633. Details of changes made are given in section 9.
3.1	Core Technical Team	16/12/2005	Change Request MIM-CR-0659. Revisions to interactions due to changes with Infrastructure artefacts.
3.2	C&M Development Team	05/05/2006	Change Requests CR-0676, CR-0707. Change to a cardinality in PDS Successful Retrieval message, and changes for batching. Full details are given in section 9.
4.0	C&M Development Team	17/11/2006	MIM-CR-0742: Queries remodelled to use the new query format. MIM-CR-0701 New artefact naming convention. CR-0742: all changes required in order to meet the requirements specified in the 2007-A Demographics Design Interface Model, and other documents. Full details of all changes are given in section 9.
4.1	C&M Development Team	15/12/2006	CR-0747, CR-0749, CR-0751: Changes required as a result of reviews. Full details are given in section 9.
4.2	C&M Development Team	26/01/2007	CR-AAA: Changes required as a result of review. The Retrieve Patient Response and the NHAIS Update Request message carry information about the paperRecordTransferFlag. Full details are given in section 9.
4.3	C&M Development Team	12/04/2007	Resolve Schema and hyperlink issues raised in MIM 5.5.00. Move XML Example messages to a subdirectory within the Examples directory.

 

 

1    Overview

The message definitions accessible from within this document have been defined to support a number of business processes, namely:

• Tracing patient details;
• Retrieving patient details;
• Confirming patient details;
• Allocating a NHS number for a set of patient details;
• Updating patient details (with death details, general administrative details or a change in consent status).

 

 

Use of Structured Address Format

There is an ongoing debate on the use of a defined structured address format. Until an IQAP decision has been reached on the appropriate structure the message format will use a 5 line unstructured format with Post Code and PAF key.

 

Use of Advanced Trace

There is an Information Governance directive to meet Caldicott guidance that when carrying out an Advanced Trace, no more information can be returned to the User than they are searching upon - until the number of returns is equal to one. It has been agreed for performance purposes that this will be managed at the local level.

 

Sensitivity Information Status

It is important that the sensitivity/confidentiality flags are dealt with in accordance with the IQAP Stop-noting MOU. The Successful Retrieval, Trace Match and NHS Number Confirmation messages return the 'Y', 'S', and 'B' values. These are for LSP system use only for managing behaviour around each status, they must not be displayed to the user.

 

 

 

2    Storyboards

2.1    Simple Trace

2.1.1    Individual Tracing

Example 1

 

Peter Parkinson has a consultation with Dr Jean Genome today to discuss the likelihood that he has inherited Parkinsons disease. Peters father died last year so Peter gives his permission for Dr Genome to look at his father Johns records. Dr Genome enters Johns name, sex, date of birth, date of death and postcode onto the system and performs PDS Simple Trace Query.

 

Example 2

 

Kari Kidd, a 2 year old who is failing to thrive, is taken by her mother Mary to a Paediatric Clinic following referral by their GP. Upon arrival she is checked in by Jane the clerk. Jane asks Mary basic details such as Karis full name, post code, sex and date of birth and uses them to do a PDS Simple Trace Query.

 

Example 3

 

Julie Partner, a diabetic since she was a child, is taken into the Accident and Emergency department of GHH in a confused state by her close friend John. Tracy Record the receptionist does a PDS Simple Trace Query using the details known by John which are Julies name, her date of birth and her gender. Initially Tracy forgets to enter a date of birth into the query and gets a Query Act Failed message saying Response failure due to inadequate, incorrect or invalid information in request. Further descriptive text in the response indicates that a mandatory item is missing. Tracy repeats the query with all mandatory items but unfortunately this is insufficient to distinguish Julie from several other possible matches. As PDS Simple Trace Query can only return information where there is a single record matching, PDS returns a Query Act Failed message saying Multiple match number of entries exceed current operational limit for number of matches returned

2.1.2    Batch Tracing

The following describes batching for 2006-B (simple trace scenario) functionality for a local PAS system at the A&E in Exeter is about to become NCRS compliant. It has a number of entries for patients without NHS Numbers. In order to reconcile its database against the PDS it sends a batch of PDS Simple Trace Query interactions, including the details of the patients without numbers. The PDS responds with a batch containing:

• PDS Simple Trace Query Response interactions for all the exact matches it has found, with the local system is updated accordingly;

• Query Act Failed interactions for all cases where an exact match was not possible; these are noted and investigated individually.

2.2    Advanced Trace

 

Example 1

 

Amandeep Archive is processing medical records of dead patients in preparation for archive. One of her tasks is to check that the information on the labels is correct. Amandeep enters the address, sex, date of birth, date of death, NHS number, name (surname, initial and prefix) and GP code and requests no history. She then performs a PDS Advanced Trace Query which returns a single match to the patient. Amandeep checks the details and marks the file as checked and ready for archive.

 

Example 2

 

Dr Greg Practice is driving to work and witnesses a road traffic accident. One casualty is unconscious but Dr Practice recognises him as Mr Wallace who came to see him last month. Dr Practice assists the paramedics and provides as many demographic details for Mr Wallace as he can remember.

At A&E Tracey Record the receptionist performs a PDS Advanced Trace Query on Mr Wallace using sex, date of birth range and family name and initial and GP code provided by Dr Practice. She also requests history to assist her in identifying Mr Wallaces record.

 

 

Example 3

 

Amandeep Archive is processing medical records of dead patients in preparation for archive. One of her tasks is to check that the information on the labels is correct. One of the labels is smudged so Amandeep enters the address, the postcode with a wildcard, sex, date of birth, date of death, NHS number, name (surname, initial both with wildcards) and GP code and requests no history. She then performs a PDS Advanced Trace Query.

 

Example 4

 

Eve Everywoman has moved out from her parents house in Scotland to a new apartment in London and soon after visits a local GP surgery to register for services. She has enjoyed good health and has not visited her previous GP for many years. Jack Puttin who is working on reception tries several PDS searches with PDS Advanced Trace Query using parts of Eves name, date of birth ranges, sex and various combinations of past addresses that Eve has resided in but PDS replies in each case with No Match to a Service User record within a Query Act Failed message. This is because there has been no automatic bulk transfer of Scottish patient demographic details to the PDS database and Eve is simply not present within the system.

 

2.3    Trace Response

 

Example 1

 

See Simple Trace Example 1. Jean Genomes search for Peters father John is successful and only one match is found. A PDS Simple Trace Query Response returns the NHS number, usual address, telephone numbers, current usual name, sex, date of birth, date of death, status of death notification and GP. She then uses this information to access Johns records to see if any there is any clinical information relating to Parkinsons disease.

 

Example 2

 

See Advanced Trace Example 2. Tracey Record receives back a PDS Advanced Trace Query Response containing two matches to her PDS Advanced Trace Query for Mr Wallace. Although Tracey requested history, neither record contained history. Both records contain NHS number name, sex, date of birth and current GP but one record also contains a date of death. Tracey is looking at the record for the live patient when one of the paramedics comes past with the news that Mr Wallace has come around and given his date of birth. Tracey checks that the record she is viewing matches Mr Wallaces date of birth and selects it.

 

Example 3

 

See Simple Trace Example 2. Jane receives back the PDS Simple Trace Query Response for Kari Kidd showing the NHS number and name. The other details (address, telecommunications and GP) have been suppressed because the Sensitivity Information Status (Confidentiality Code) is set to S.

Jane completes the check in process and sends Mary and Kari through for their consultation.

 

Example 4

 

See Advanced Trace Example 3. Amandeep receives back the PDS Advanced Trace Query Response which contains two records. The first record contains NHS number, name, sex, full date of birth, full date of death and GP. The second record contains the NHS number and name and the remaining details are suppressed due to the Sensitivity Information Status being set. Amandeep checks the first record and confirms that the details match those on the label and on the front page of the file. Amandeep re labels the file and marks it as checked and ready for archive.

2.4    Retrieval Request and Result

2.4.1    Individual Retrieval

Example 1

 

Tracey Record is setting up a clinic list for Dr Richard Kildare. For each patient on the list Tracey performs a PDS Retrieval Query requesting only the Serial Change number. When a PDS Retrieval Query Response is received with the patient Serial Change number this number is checked against the one held locally. If they are the same (i.e. no updates have been made to the patient information on PDS) then Tracey adds the patient to the clinic list.

 

Example 2

 

Tracey Record is supervising the orthopaedic out patient clinic. When each patient arrives, Tracey performs a PDS Retrieval Query and requests all person demographics including history. She then checks the details returned in the PDS Retrieval Query Response with the patient before sending the patient through to the waiting room.

 

Example 3

 

Adam Everyman has returned from his GP with a referral to see a consultant at Good Health Hospital on the following Monday. Adam normally takes a close friend Sandra Proxy with him when he makes a trip to GHH but she isnt available on that day. Adam asks if she will cancel the appointment for him. Sandra telephones Oliver Operator at the e-booking service who checks to see if Sandra is a valid proxy for Adam. Oliver sends a PDS Retrieval Query to PDS including Adams NHS number and a parameter indicating that Proxy information is required. Oliver is able to see from the results returned in the PDS Retrieval Query Response message that Sandra is a valid proxy and therefore rearranges the appointment as requested.

 

Example 4

 

Delia Death receives notification from Dr Richard Kildare that a patient Ann Terminal has died in the hospital. Brenda performs a successful trace on Ann Terminal and then performs a PDS Retrieval Query requesting name, date of birth, date of death and sex. Delia is able to see the results in the PDS Retrieval Query Response message and from this she can see that the Date of Death has already been updated on PDS.

 

Example 5

 

GP Dr Clara Certifieds practice is no longer dispensing prescriptions to their patients. Rita Ritalin has her regular appointment with Dr Certified today. Dr Certified performs a PDS Retrieval Query requesting pharmacy details for Rita. From the PDS Retrieval Query Response message Dr Certified can see that Rita has the practice pharmacy as her nominated pharmacy. During the consultation, Dr Certified explains that the practice no longer has a dispensary and suggests some alternative pharmacies to Rita.

 

Example 6

 

Neville Nuclear visits his GP Clara Certified because of feeling tired. Dr Certified completes a request form, takes a specimen of blood and sends it to the Pathology Laboratory at Good Health Hospital for a range of thyroid function tests. Christopher Clerk the receptionist at the laboratory notices that the Laboratory Information Management System (LIMS) has no recorded address for Neville. Christopher uses the NHS Number on the form to retrieve address details using the PDS Retrieval Query. He is only interested in current address so does not ask for historic data. Unfortunately he misreads a 5 for a 6. PDS recognizes the check digit is now incorrect and issues a Query Act Failed message containing the code for Response failure due to inadequate, incorrect or invalid information in request.

2.4.2    Batch Retrieval

One of the consultants at the Optometry department at the RD&E Hospital in Devon is taken ill suddenly and looks likely to be off on long term sick for 3 months. The department manager immediately attempts to rearrange cover for her, but is forced to reschedule a number of appointments within that period. In order to inform all the patients affected it is decided that each one will be sent a letter explaining the situation and offered an alternate appointment. Their local system is NCRS compliant so in order to ensure that the letters go to the most up to date addresses, the administrator puts together a Batch of Retrieval Requests, with NHS Numbers, for all the patients affected. This is sent to the SPINE via a batch of PDS Retrieval Query interactions, which using the batching mechanism described in the Infrastructure manual. The SPINE returns a batch of PDS Retrieval Query Response interactions in response, with details for each patient. The administrator then proceeds to update the local system where necessary and produce the letters required.

2.5    Confirm NHS number

 

Example 1

 

Tracey Record has a list of patients who need to be invited for follow up to Dr Richard Kildares clinic. She sets up a list of NHS numbers and requests a PDS Confirm NHS Number Query for each number. Tracey checks the details returned (NHS Number, address, name, sex, date of birth, date of death and death notification status) in the PDS Confirm NHS Number Query Response messages initially to make sure the patients are still alive. Where a date of death and a death status has been returned Tracey makes a note to follow these up later. For all the other patients, Tracey uses the details returned in the PDS Confirm NHS Number Query Response messages to set up a mail merge file. Tracey then uses this mail merge file to issue an invitation letter to each patient for the clinic.

 

Example 2

 

Adam Everyman has a fall at home and visits his GP Dr Clara Certified for a consultation. Dr Certified decides to send Adam to Good Health Hospital (GHH) hospital for an X-ray of his arm and arranges by telephone with Brenda Book the appointments clerk for Adam to attend the following morning. Brenda enters the request into the Radiology Information System (RIS) using details she finds on the local Patient Management System (PMS).

The last time Adam visited the GHH was five years previously when he was assigned an NHS number. Unfortunately this was set up manually as PDS was not operational and a mistake was made when the number was entered.

The RIS at GHH is configured to make sure that details on all patients expected to visit the Department on any particular day are as up to date as possible. Prior to Alans appointment an PDS Confirm NHS Number Query is started by Brenda containing Adams patient identifier so that she can confirm the accuracy of the locally held data. Due to the error in the NHS number held by the local PMS, PDS can find no trace Adams record and returns an error in the Query Act Failed message indicating there was No Match to a Service User record.

 

2.6    Allocate NHS number

Example 1

 

Albert Ensten has returned to England after spending many years abroad. Albert has changed his name several times and cant remember any addresses he had in England. He does remember being in hospital as a child in Devon. Amy Armstrong tries several PDS Advanced Trace Querys using some of the names Albert has used over the years but she can find no record for Albert. She decides to allocate an NHS Number and completes the on screen record with the information that Albert provides, address, telephone, name, sex, date of birth. She also asks Albert for his preferences and adds his preferred contact method, preferred written communication format and preferred language and interpreter required. She also marks the record to say that Albert has had previous NHS contact. This is transmitted to PDS as a PDS NHS Number Allocation Request and a NHS number is allocated and returned via the PDS NHS Number Allocation Request Accepted.

 

Example 2

 

Eve Everywoman has moved out from her parents house in Scotland to a new apartment in London and soon after visits her local PCT to register for NHS services. She has enjoyed good health and has not visited her previous GP for many years. Martha Puttin who is working on reception attempts several PDS Advanced Trace Querys but as she can find no previous record she decides to allocate a NHS number. She carefully completes the on screen record detailing Eves full name, address, date of birth, sex and telephone number as well as the GP practice number. Martha also marks the record to show that Eve has no previous NHS contact (in England).This is transmitted to PDS as a PDS NHS Number Allocation Request and a NHS number is allocated and returned via the PDS NHS Number Allocation Request Accepted.

 

2.7    Allocate NHS Number Failure

Eve Everywoman has moved out from her parents house in Scotland to a new apartment in London and soon after visits a local GP surgery to register for services. She has enjoyed good health and has not visited her previous GP for many years. Jack Puttin who is working on reception attempts a PDS Advanced Trace Query several times but as he can find no previous record he decides to allocate a NHS number. He completes the on screen record detailing Eves full name, date of birth, sex and telephone number as well as the GP practice number. This is transmitted to PDS as a PDS Allocate NHS Number Request. Unfortunately Jack omits to enter either a permanent or temporary address in the request and as this is a mandatory item PDS responds with an error in the Application Acknowledgement. Additional text is also supplied detailing the problem.

2.8    General Update

2.8.1    Updating death information

A GP at the Good Health Medical Centre, Dr Clara Certified, is called out to see one of her patients, Mr. Ned Nuclear by his wife Nancy. Ned has been suffering from carcinoma of the lung and despite chemotherapy his health has continued to decline. After examining Ned carefully Clara pronounces him as dead. She completes a death certificate for the family and after helping the family make arrangements Clara returns to the surgery. She updates Neds PDS record using the PDS General Update Request including the date and time of death. PDS responds with a code meaning the update was performed successfully within the PDS General Update Request Accepted message.

2.8.2    Updating general information

Example 1

 

Maria Sanchez registered for NHS services some time ago. She has recently married and moved in to a new home with her husband and his children. Maria visits her GP surgery and Jack Puttin retrieves Marias details and enters Marias new name, address and telephone numbers. He also adds details of her step children as family/close contacts. Maria has brought this information in written on paper so Jack asks Maria whether she would like to have a language or interpreter recorded on her record. Maria agrees and Jack enters Marias language and that she would like an interpreter. Jack updates Marias record using the PDS General Update Request and PDS responds with a PDS General Update Request Accepted message.

 

Example 2

 

Eve Everywoman registered for NHS services some time ago. She works as an actress, has recently been in a very successful film and as a result she is now a well known celebrity. On the advice of her legal advisors she writes to her local Primary Care Trust requesting that her records are updated. She asks that her stage name of Sarah Showtime and her move to Marilyn Mansions are noted. The Records Supervisor at the PCT, Maria Manager, performs a PDS General Update Request supplying Eves alias name and new address with a date effective taken from the letter. Unfortunately the date on the letter is the 30^th of February so PDS responds with an Update failed code within the Application Acknowledgement message plus additional text detailing the problem.

2.8.3    Updating consent information

 

Example 1

 

Julie Partner visits her GP with a persistent cough and cold.  It has been some time since Julie has visited the Good Health Medical Centre so Jack Puttin checks her records using PDS.  He notices that Julie is recorded as Implied Consent with regard to her records being shared with other NHS care professionals.  Jack asks her whether she has any objection to her medical records being shared in case she has to be referred.  Julie listens carefully to Jack about the benefits but decides that she does not want to give consent. Jack uses the PDS General Update Request message to inform PDS of the change from Implied Consent to Express Dissent and explains to Julie how this could affect her NHS care in the future.  PDS responds with a PDS General Update Request Accepted message back to the requesting system.

 

2.9    NHAIS Update

2.9.1    GP Registration

 

Example 1

 

Ms A Bloggs moves from Newcastle to Birmingham where she decides to register with her local GP Practice. Ms Bloggs arrives at the front desk of her local GP surgery where the receptionist, Betty Barker, asks her to complete a registration form for new patients. Betty enters the details, from the form, into the GP system and sends the batch at end of their working day to the NHAIS mail box.

 

NHAIS receives the batch and unpacks the acceptances and processes them immediately by sending a Trace message (either in response to a simple or advance trace) to PDS with the demographic details provided by Ms Bloggs. PDS finds an exact match for Ms Bloggs and returns details of her NHS Number and other demographic data held.

 

NHAIS then sends a PDS NHAIS Update Request message to PDS to notify that Ms Bloggs now has a new registered GP Practice. PDS responds to NHAIS with a PDS NHAIS Update Request Accepted message as notification that the update has been successful. A new LR is created between the patient and the new GP Practice. At this point NHAIS updates its patient list and sends the approval on to the new GP Practice in the next overnight batch. As Ms Bloggs is a transfer in from another NHAIS area, NHAIS sends an acceptance transaction to CHRIS. CHRIS updates its database and sends a deduction to the Newcastle NHAIS system which sends a deduction to the former practice requesting them to forward on Ms Bloggs Lloyd George envelope.

2.9.2    Removal from GP Practice list

 

Example 1

 

Dr Peter Parlour is called to the home of John Dory, a patient he has been treating for heart failure. When he arrives, Mrs Dory tells him that John, who has been sleeping downstairs, did not wake up this morning and she thinks he has passed away. Dr Parlour examines John and confirms that he has died. He writes a death certificate and ensures that Mrs Dory has someone to help her with the arrangements. On return to the surgery, Dr Parlour advises Mary Manager, the practice administrator, that John has died. Later that day, Mary enters Johns details into a removal screen to record the death. The GP system sends the removal request to NHAIS, notifying it of the death. NHAIS retrieves Johns details from PDS. As the reason for removal is death the removal is processed immediately and NHAIS sends the removal to PDS as a PDS NHAIS Update Request, where it is recorded as an informal death notification.

2.9.3    Miscellaneous update

 

Example 1

 

On an ante-natal visit to her GP Practice, Maggie May tells Peter Piper, the receptionist that they are moving to a larger house a few streets away. Peter checks that the new address is within the practice boundary and enters the new address into the GP system, which sends it in a batch at the end of the working day to the NHAIS mail box. NHAIS receives the batch and unpacks the transaction and processes it immediately by sending a Retrieval Request message to PDS with the NHS Number. PDS finds an exact match for Maggie and returns details of her NHS Number and other demographic data held. NHAIS sends the amendment to PDS within a PDS NHAIS Update Request and updates its own records. As CHRIS does not hold addresses, NHAIS does not need to notify it

 

2.10    Cross Check Trace

2.10.1    Successful Cross Check Trace Query

Example 1

 

Tracey Record has a list of patients who need to be invited for follow up to Dr Richard Kildares clinic. She sets up a list of NHS numbers and requests a Cross Check Trace to validate each number against pre-selected demographic information, namely either:

• New Style NHS Number, Surname, Forename and Date of Birth,

• or New Style NHS Number and Date of Birth

 

Tracey checks the details returned, in the trace response namely:

• New Style NHS Number

• Name

• Address

• Date of Birth

• Gender

• Telecommunication Information

• Patient Care Provider Details

• Date of Death

• Death Notification Status

• NHS Number and Date of Birth

• Registration Details

• Baby Tracing information

 

Note:  Tracey record checks the PDS Cross Check Trace Query Response message and where a date of death and a death status has been returned Tracey makes a note to follow these up later.

 

For all the other patients, Tracey uses the details returned in the PDS Cross Check Trace Query Response messages to set up a mail merge file. Tracey then uses this mail merge file to issue an invitation letter to each patient for the clinic.

 

2.10.2    No Trace of a Patient's Record

Example 2

 

Adam Everyman has a fall at home and visits his GP Dr Clara Certified for a consultation. Dr Certified decides to send Adam to Good Health Hospital (GHH) hospital for an X-ray of his arm and arranges by telephone with Brenda Book the appointments clerk for Adam to attend the following morning. Brenda enters the request into the Radiology Information System (RIS) using details she finds on the local Patient Management System (PMS).

 

The last time Adam visited the GHH was five years previously when he was assigned an old style NHS number. Unfortunately this was set up manually as PDS was not operational and a mistake was made when the number was entered.

 

The RIS at GHH is configured to make sure that details on all patients expected to visit the Department on any particular day are as up to date as possible. Prior to Alans appointment a Cross Check Trace query is started by Brenda containing Adams patient identifier so that she can confirm the accuracy of the locally held data. Due to the error in the NHS number held by the local PMS, PDS can find no trace of Adams record and returns a Query Act Failed indicating there was no match, via one of the following responses either:

• NHS Number Not Found

• NHS Number Invalid

 

2.11    Batch Trace Query (for 2007 - A)

 

Susan Smith, the Trust's Data Quality Manager has a list of patients whose records need to be checked for accuracy against information held on the PDS.  She accesses the local PAS system and creates a batch file and the PAS system submits this as a batch of PDS Batch Trace Query interactions to the NHS spine, via HL7 messaging.

 

Each item in the batch contains as a minimum the following information for a preliminary Cross Check Trace:

• New Style NHS Number, Surname, Forename and Date of Birth,

• or New Style NHS Number and Date of Birth

 

If this fails then an Advanced Trace is performed on the PDS using the additional information provided:

• Full Surname, Full Forename, Gender (optional), Full Date of Birth, Post Code (optional), PAF Key (optional), address line(s) (optional), Date of Death or Date of Death range (optional), GP Code or GP Practice Code (optional)

 

NB The new style NHS number is not traced upon.

 

The PDS responds with a batch containing:

 

 

2.12    Birth Information Messages

2.12.1    Successful Create Initial Record and Birth Notification

Baby born in an NHS CRS Compliant NHS Trust Maternity Unit, sending to a non-NHS CRS compliant NHS PCT Child Health Department from Release 2007.

Mrs A Brown, having had complications during pregnancy, has been booked into the consultant led maternity unit at her local District General Hospital, which has an NHS CRS and NN4B compliant maternity system. Her midwife has already forwarded her notes to the delivery unit so that they have her details. Mrs A Brown feels unwell and decides to ring her midwife, who advises that she be admitted to the maternity unit so as she can be monitored. The consultant decides that a Caesarean Section would be the best course of action for both mother and baby, and Mrs Brown agrees to the surgical procedure. Baby is born and when the midwife has attended to mother and baby, enters details of the birth on the maternity system. Mrs Brown and her husband have decided on a forename for their baby Bobby and will have the family surname. The PDS Create Initial Record Request message is sent from the NHS CRS-compliant Maternity System to Spine, which invokes the tracing of the baby on the PDS to make sure that the birth has not already been registered. Once the Spine has decided that the birth is indeed a unique event, the PDS issues an NHS Number and this number is successfully added to the maternity system record for the baby. The midwife completes the relevant sections on the maternity system and closes the session.
The Spine determines that the (partner) Child Health Department is not yet Spine accredited and so Spine sends a full birth notification via TMS to the NN4B Service, so that the statutory function of reporting the birth can be successfully carried out, along with reporting to other National System not yet NHS CRS-compliant e.g. NHS Newborn Hearing Screening; ONS Message Handling Service.

2.12.2    Create Initial Record Request Rejected - Duplicate Found

Baby born in an NHS CRS Compliant NHS Trust Maternity Unit, sending to a non-NHS CRS compliant NHS PCT Child Health Department from Release 2007.

Mrs B Cumming is expecting twins and has been booked into the consultant led maternity unit at her local General Hospital, which has an NHS CRS and NN4B compliant maternity system. Her midwife has already forwarded her notes to the delivery unit so that they have her details. Mrs Cumming rings the hospital to say her contractions are between 4 and 5 minutes apart, and is told to come to the maternity unit as she may well deliver within the next few hours. Mrs Cumming and her husband have not decided on forenames for their babies, although they will have the family surname.

 

After delivering the babies and making sure that mother and both babies are healthy and comfortable, the lead midwife then actions the request for an NHS Number for each baby from the PDS by submitting a request on the maternity system. The details for Twin One Cumming are entered, and the midwife waits whilst an NHS Number is obtained. The PDS Create Initial Record Request message is sent from the NHS CRS-compliant Maternity System to Spine, which invokes the tracing of the baby on the PDS to make sure that the birth has not already been registered. Once the Spine has decided that the birth is indeed a unique event, the PDS issues an NHS Number and this number is returned in a PDS Create Initial Record Request Accepted message, and is successfully added to the maternity system record for the baby. The midwife completes the relevant sections on the maternity system and closes the session.

 

The details for Twin Two Cumming are entered, and the midwife waits whilst an NHS Number is obtained. The PDS Create Initial Record Request message is sent from the NHS CRS-compliant Maternity System to Spine, which invokes the tracing of the baby on the PDS to make sure that the birth has not already been registered. The Spine detects that the birth has already been registered, and issues a PDS Create Initial Record Request Rejected (Duplicate Found) to the NHS CRS-compliant maternity system, which processes the message and indicates to the midwife that an NHS Number has not been returned. The maternity system also shows the midwife details of the birth already on the Spine with seemingly the same details as the one just entered, so that the midwife can clearly see why the second birth has not been issued with an NHS Number. On checking the details, the midwife realizes that birth data relating to the first baby has been used instead of the second, hence the reason for the possible duplicate.

 

The midwife checks the details for the second baby, and amends the relevant fields on the maternity system, and the midwife waits whilst an NHS Number is obtained. The PDS Create Initial Record Request message is sent from the NHS CRS-compliant Maternity System to Spine, which invokes the tracing of the baby on the PDS to make sure that the birth has not already been registered. Once the Spine has decided that the birth is indeed a unique event, the PDS issues an NHS Number and this number is returned in a PDS Create Initial Record Request Accepted message, and is successfully added to the maternity system record for the second baby. The midwife completes the relevant sections on the maternity system and closes the session.

 

3    Application Roles

The applications involved in the business processes listed above play specific roles. These, along with a description of the interactions associated with each role, are identified below.

3.1    Local Application Roles

3.1.1    PDS Query Placer - QUPA_AR000001UK01

The PDS Query Placer is the initiator of any type of query to the PDS. Types of query include: Trace, Advanced Trace, Retrieval and Confirm NHS Number.

3.1.2    PDS Registration Requester - PRPA_AR000200UK01

The PDS Registration Requester is the initiator of a request to register a record on the PDS.

3.1.3    PDS Update Requester - PRPA_AR000201UK01

The PDS Update Requester is the initiator of a request to perform an update to a Service User record on the PDS.

3.2    PDS Application Roles

3.2.1    PDS Query Fulfiller - QUPA_AR000002UK01

The PDS Query Fulfiller responds to queries sent to the PDS. Types of query include: Trace, Advanced Trace, Retrieval and Confirm NHS Number.

3.2.2    PDS Registration Fulfiller - PRPA_AR000202UK01

The PDS Registration Fulfiller represents the PDS acting in the role of fulfiller of registration requests such as registering a new record on the PDS.

3.2.3    PDS Update Fulfiller - PRPA_AR000203UK01

The PDS Update Fulfiller is the PDS acting in the role of updater of information relating to a patient registered on the PDS.

3.2.4    PDS Informer - PRPA_AR000205UK01

The PDS Informer is the PDS acting in the role of informer to other systems of information relating to a patient registered on the PDS.

3.3    Other Application Roles

3.3.1    PDS NHAIS Update Request Placer - PRPA_AR000204UK01

This role represents the NHAIS system when acting in the role of updater of information relating to a patient registered on the PDS.

3.3.2    PDS Tracker - PRPA_AR000206UK01

This role represents a system acting in the role of receiver/tracker of information relating to a patient registered on the PDS.

 

 

4    Trigger Events

The trigger events which cause each interaction to be initiated are identified below.

4.1    PDS Simple Trace Query - QUPA_TE000004UK01

This trigger event signals that a new Simple Trace Query has been initiated in order to search for a patient given a suitable combination of name, DoB and postcode.

4.2    PDS Advanced Trace Query - QUPA_TE000005UK01

This trigger event signals that a new Advanced Trace Query has been initiated in order to search for a patient using a wider range of search parameters that in a PDS Simple Trace Query.

4.3    PDS Simple Trace Query Response - QUPA_TE000006UK01

This trigger event signals that the result of a PDS Simple Trace Query is that a single identifiable patient has been found on the PDS.

4.4    PDS Advanced Trace Query Response - QUPA_TE000011UK01

This trigger event signals that the result of a PDS Advanced Trace Query is that one or more (but not more than a limit constrained by the PDS) identifiable patients were found on the PDS.

4.5    PDS Retrieval Query - QUPA_TE000007UK01

This trigger event signals that a new request to retrieve a patient's demographic details has been initiated.

4.6    PDS Retrieval Query Response - QUPA_TE000008UK01

This trigger event signals that the result of a PDS Retrieval Query is that the identified patient has been found on the PDS, and that demographic details are being returned for that patient.

4.7    PDS Confirm NHS Number Query - QUPA_TE000009UK01

This trigger event signals that a new request to confirm a patient's NHS number has been initiated.

4.8    PDS Confirm NHS Number Query Response - QUPA_TE000010UK01

This trigger event signals that the result of a PDS Confirm NHS Number Query is that the identified patient has been found on the PDS, and that some demographic details are being returned for that patient.

4.9    PDS NHS Number Allocation Request - PRPA_TE000200UK01

This trigger event signals that a new request to allocate a NHS number for a patient has been initiated.

4.10    PDS NHS Number Allocation Request Accepted - PRPA_TE000201UK01

This trigger event signals that the result of a PDS NHS Number Allocation Request is that a newly allocated NHS number is being returned for that patient.

4.11    PDS General Update Request - PRPA_TE000203UK01

This trigger event signals that some patient details, possibly including consent and / or death information, have been changed, corrected or some new details are available, and are to be recorded on the PDS.

4.12    PDS General Update Request Accepted - PRPA_TE000202UK01

 This trigger event signals that the result of a PDS General Update Request is that the details have been updated on PDS

4.13    PDS NHAIS Update Request - PRPA_TE000204UK01

This trigger event signals that some patient details have been changed, corrected or some new details are available on NHAIS, and the update is to be recorded on the PDS.

4.14    PDS NHAIS Update Request Accepted - PRPA_TE000209UK01

This trigger event signals that the result of a PDS NHAIS Update Request is that the details have been updated on PDS.

4.15    PDS Batch Trace Query - QUPA_TE000012UK01

This trigger event signals that a new Batch Trace Query has been initiated in order to trace a patient's details for data cleansing purposes.

4.16    PDS Batch Trace Query Response - QUPA_TE000013UK01

This trigger event signals that the result of a PDS Batch Trace Query (which consists of a combination of a Cross Check Trace and/or Advanced Trace on the PDS) is that a single identifiable patient has been found on the PDS.

4.17    PDS Create Initial Record Request - PRPA_TE000205UK01

This trigger event signals that a new request to create a new record for a patient has been initiated.

4.18    PDS Create Initial Record Request Accepted - PRPA_TE000206UK01

This trigger event signals that the result of a PDS Create Initial Record Request is that no duplicate records were found on the PDS and so a new record was created.

4.19    PDS Create Initial Record Request Rejected (Duplicate Found) - PRPA_TE000207UK01

This trigger event signals that the result of a PDS Create Initial Record Request is that one or more duplicate records were found on the PDS and so a new record was not created.

4.20    PDS Initial Record Created Notification - PRPA_TE000208UK01

This trigger event signals that a new record was added to the PDS, and a notification is to be sent.

4.21    PDS Cross Check Trace Query - QUPA_TE000014UK01

This trigger event signals that a new Cross Check Trace query has been initiated in order to search for a patient, to determine whether the details held on the PDS for that patient are consistent with the details held locally.

4.22    PDS Cross Check Trace Query Response - QUPA_TE000015UK01

This trigger event signals that the result of a PDS Cross Check Trace Query is that a single identifiable patient has been found on the PDS.

 

 

5    Interaction Diagrams

This section provides diagrammatic representation of which interactions are related to which application roles.

5.1    Trace Query interactions

 

5.2    Retrieval Query interactions

 

5.3    Confirm NHS Number Query interactions

 

5.4    NHS Number Allocation interactions

 

5.5    General Update interactions

 

5.6    NHAIS Update interactions

 

5.7    Create Initial Record interactions

 

5.8    Initial Record Created (Birth) Notification interactions

 

6    Interactions

6.1    PDS Simple Trace Query - QUPA_IN000005UK01

This interaction occurs when a request to trace a patient on the PDS is started, using a limited set of parameters. The PDS Query Placer sends a PDS Simple Trace Query, with the various patient details, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Simple Trace Query	QUPA_TE000004UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Simple Trace Query	QUPA_MT000001UK01

 

 

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Simple Trace Query Response: QUPA_IN000007UK01

 

NB: The interactions listed in the above table can be batched in response to a batch of PDS Trace Query Started interactions, with one or other or both types of interaction being present in the batched response.

 

6.2    PDS Advanced Trace Query - QUPA_IN000006UK02

This interaction occurs when a request to trace a patient on the PDS using advanced trace mechanisms is started. The PDS Query Placer sends a PDS Advanced Trace Query, with the various patient details, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Advanced Trace Query	QUPA_TE000005UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Advanced Trace Query	QUPA_MT000002UK02

 

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Advanced Trace Query Response: QUPA_IN000011UK02

 

6.3    PDS Simple Trace Query Response - QUPA_IN000007UK01

This interaction occurs when a request to trace a patient on the PDS results in a successful match. The PDS Query Fulfiller sends a PDS Simple Trace Query Response, with a number of data fields relating to the patient or patients, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Simple Trace Query Response	QUPA_TE000006UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Simple Trace Query Response	PRPA_MT000200UK01

 

 

This interaction may be batched in response to a batch of PDS Simple Trace Query interactions, using the generic batching mechanism described in the Infrastructure domain.  Click here for details of this mechanism.

6.4    PDS Advanced Trace Query Response - QUPA_IN000011UK02

This interaction occurs when a request to trace a patient on the PDS results in a successful match. The PDS Query Fulfiller sends a PDS Advanced Trace Query Response, with a number of data fields relating to the patient or patients, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Advanced Trace Query Response	QUPA_TE000011UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Advanced Trace Query Response	PRPA_MT000207UK02

 

6.5    PDS Retrieval Query - QUPA_IN000008UK02

This interaction occurs when a request to retrieve patient details from the PDS is started. The PDS Query Placer sends a PDS Retrieval Query, with the patient's identifier, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Retrieval Query	QUPA_TE000007UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Retrieval Query	QUPA_MT000003UK02

 

 

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Retrieval Query Response: QUPA_IN000009UK03

 

NB: The interactions listed in the above table can be batched in response to a batch of PDS Retrieval Query interactions, with one or other or both types of interaction being present in the batched response.

 

6.6    PDS Retrieval Query Response - QUPA_IN000009UK03

This interaction occurs when a request to retrieve patient details from the PDS results in a successful match on the patient identifier and all criteria for retrieving the data are met. The PDS Query Fulfiller sends a PDS Retrieval Query Response, with a number of data fields, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Retrieval Query Response	QUPA_TE000008UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Retrieval Query Response	PRPA_MT000201UK03

 

 

This interaction may be batched in response to a batch of PDS Retrieval Query interactions, using the generic batching mechanism described in the Infrastructure domain.Click here for details of this mechanism.

6.7    PDS Confirm NHS Number Query - QUPA_IN000016UK02

This interaction occurs when a request to confirm patient details from the PDS is started. The PDS Query Placer sends a PDS Confirm NHS Number Query, with a set of details relating to the patient, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Confirm NHS Number Query	QUPA_TE000009UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Confirm NHS Number Query	QUPA_MT000004UK01

 

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Confirm NHS Number Query Response: QUPA_IN000010UK02

 

6.8    PDS Confirm NHS Number Query Response - QUPA_IN000010UK02

This interaction occurs when a request to confirm patient details from the PDS is successful. PDS Query Fulfiller sends a PDS Confirm NHS Number Query Response, with a number of data fields to reduce the need for further queries following confirmation, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Confirm NHS Number Query Response	QUPA_TE000010UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Confirm NHS Number Query Response	PRPA_MT000202UK02

 

 

6.9    PDS NHS Number Allocation Request - PRPA_IN000200UK03

This interaction occurs when a request to allocate an identifier for a patient is started. The PDS Registration Requester sends a PDS NHS Number Allocation Request, with a set of details relating to the patient, to the PDS Registration Fulfiller.

 

Sending Role	PDS Registration Requester	PRPA_AR000200UK01
Receiving Role	PDS Registration Fulfiller	PRPA_AR000202UK01
Trigger Event	PDS NHS Number Allocation Request	PRPA_TE000200UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS NHS Number Allocation Request	PRPA_MT000203UK03

 

 

Receiver Responsibilities

Reason	Interaction
Request failed	Application Acknowledgement: MCCI_IN010000UK13
Request successful	PDS NHS Number Allocation Request Accepted: PRPA_IN000201UK01

 

6.10    PDS NHS Number Allocation Request Accepted - PRPA_IN000201UK01

This interaction occurs when a request to allocate an identifier for a patient has been accepted by the PDS. The PDS Registration Fulfiller sends a PDS NHS Number Allocation Request Accepted to the PDS Registration Requester providing a newly allocated NHS number.

 

Sending Role	PDS Registration Fulfiller	PRPA_AR000202UK01
Receiving Role	PDS Registration Requester	PRPA_AR000200UK01
Trigger Event	PDS NHS Number Allocation Request Accepted	PRPA_TE000201UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Registration Request Accepted	PRPA_MT000204UK01

 

6.11    PDS General Update Request - PRPA_IN000203UK03

This interaction occurs when a change in the patient's administrative details, possibly including consent and death information, is recorded. The PDS Update Requester sends a PDS General Update Request, with the changed, corrected or new details to the PDS Update Fulfiller.

 

Sending Role	PDS Update Requester	PRPA_AR000201UK01
Receiving Role	PDS Update Fulfiller	PRPA_AR000203UK01
Trigger Event	PDS General Update Request	PRPA_TE000203UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS General Update Request	PRPA_MT000206UK03

 

 

Receiver Responsibilities

Reason	Interaction
Update failed	Application Acknowledgement: MCCI_IN010000UK13
Update successful	PDS General Update Request Accepted: PRPA_IN000202UK01

 

6.12    PDS General Update Request Accepted - PRPA_IN000202UK01

This interaction occurs when an update request to PDS has been accepted. The PDS Update Fulfiller sends a PDS General Update Request Accepted to the PDS Update Requester.

 

Sending Role	PDS Update Fulfiller	PRPA_AR000203UK01
Receiving Role	PDS Update Requester	PRPA_AR000201UK01
Trigger Event	PDS General Update Request Accepted	PRPA_TE000202UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Update Request Accepted	PRPA_MT000205UK01

 

 

6.13    PDS NHAIS Update Request - PRPA_IN000204UK03

This interaction is sent when a change in the patient's administrative details is recorded on NHAIS and the details need to be updated on the PDS. The PDS NHAIS Update Request Placer sends a PDS NHAIS Update Request, with the changed, corrected or new details to the PDS Update Fulfiller.

 

Sending Role	PDS NHAIS Update Request Placer	PRPA_AR000204UK01
Receiving Role	PDS Update Fulfiller	PRPA_AR000203UK01
Trigger Event	PDS NHAIS Update Request	PRPA_TE000204UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS NHAIS Update Request	PRPA_MT000208UK03

 

 

Receiver Responsibilities

Reason	Interaction
Update failed	Application Acknowledgement: MCCI_IN010000UK13
Update successful	PDS NHAIS Update Request Accepted: PRPA_IN000209UK01

 

6.14    PDS NHAIS Update Request Accepted - PRPA_IN000209UK01

This interaction occurs when an NHAIS update request to PDS has been accepted. The PDS Update Fulfiller sends a PDS NHAIS Update Request Accepted to the PDS NHAIS Update Request Placer.

 

Sending Role	PDS Update Fulfiller	PRPA_AR000203UK01
Receiving Role	PDS NHAIS Update Request Placer	PRPA_AR000204UK01
Trigger Event	PDS NHAIS Update Request Accepted	PRPA_TE000209UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Update Request Accepted	PRPA_MT000205UK01

 

6.15    PDS Batch Trace Query - QUPA_IN000012UK02

This interaction occurs when a request to trace a patient on the PDS is started, and it is intended that the PDS perform a Cross Check Trace or Advanced Trace as appropriate. It is intended that this interaction be sent within a batch.

 

The PDS Query Placer sends a PDS Batch Trace Query, with the various patient details, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Batch Trace Query	QUPA_TE000012UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Batch Trace Query	QUPA_MT000005UK02

 

 

This interaction may be batched using the generic batching mechanism described in the Infrastructure domain.

Click here for details of this mechanism.

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Batch Trace Query Response: QUPA_IN000013UK01

 

NB: The interactions listed in the above table can be batched in response to a batch of PDS Batch Trace Query interactions, with one or other or both types of interaction being present in the batched response.

 

6.16    PDS Batch Trace Query Response - QUPA_IN000013UK01

This interaction occurs when a request to trace a patient on the PDS results in a successful match, after the PDS has run either a Cross Check Trace or Advanced Trace as a result of a Batch Trace Query. The PDS Query Fulfiller sends a PDS Batch Trace Query Response, with a number of data fields relating to the patient or patients, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Batch Trace Query Response	QUPA_TE000013UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Batch Trace Query Response	PRPA_MT000209UK01

 

 

This interaction may be batched in response to a batch of PDS Batch Trace Query interactions, using the generic batching mechanism described in the Infrastructure domain.Click here for details of this mechanism.

 

6.17    PDS Create Initial Record Request - PRPA_IN000205UK03

This interaction occurs when a request to create an initial record on the PDS and allocate an identifier for a patient is started. The PDS Registration Requester sends a PDS Create Initial Record Request, with a set of details relating to the patient, to the PDS Registration Fulfiller.

 

Sending Role	PDS Registration Requester	PRPA_AR000200UK01
Receiving Role	PDS Registration Fulfiller	PRPA_AR000202UK01
Trigger Event	PDS Create Initial Record Request	PRPA_TE000205UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Create Initial Record Request	PRPA_MT000211UK03

 

 

Receiver Responsibilities

Reason	Interaction
Request failed	Application Acknowledgement: MCCI_IN010000UK13
Request failed - duplicate record(s) found on the PDS	PDS Create Initial Record Request Rejected (Duplicate Found): PRPA_IN000207UK03
Request successful - no duplicate records found on the PDS	PDS Create Initial Record Request Accepted: PRPA_IN000206UK01

 

6.18    PDS Create Initial Record Request Accepted - PRPA_IN000206UK01

This interaction occurs when a request to create an initial record on the PDS and allocate an identifier for a patient has been accepted, and no duplicate records were found on the PDS. The PDS Registration Fulfiller sends a PDS Create Initial Record Request Accepted to the PDS Registration Requester providing a newly allocated NHS number.

 

Sending Role	PDS Registration Fulfiller	PRPA_AR000202UK01
Receiving Role	PDS Registration Requester	PRPA_AR000200UK01
Trigger Event	PDS Create Initial Record Request Accepted	PRPA_TE000206UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Registration Request Accepted	PRPA_MT000204UK01

 

6.19    PDS Create Initial Record Request Rejected (Duplicate Found) - PRPA_IN000207UK03

This interaction occurs when a request to create an initial record on the PDS and allocate an identifier for a patient has been rejected, as one or more duplicate records were found on the PDS. The PDS Registration Fulfiller sends a PDS Create Initial Record Request Rejected (Duplicate Found) to the PDS Registration Requester, providing details of the duplicate record(s) found on the PDS.

 

Sending Role	PDS Registration Fulfiller	PRPA_AR000202UK01
Receiving Role	PDS Registration Requester	PRPA_AR000200UK01
Trigger Event	PDS Create Initial Record Request Rejected (Duplicate Found)	PRPA_TE000207UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Create Initial Record Request Rejected (Duplicate Found)	PRPA_MT000210UK03

 

6.20    PDS Birth Notification - PRPA_IN000208UK03

This interaction occurs when the PDS is required to notify other systems of the creation of a new record on the PDS (which is due to a birth), and some details about the birth. The PDS Informer sends a PDS Birth Notification, with a set of details relating to the birth, to the PDS Tracker.

 

Sending Role	PDS Informer	PRPA_AR000205UK01
Receiving Role	PDS Tracker	PRPA_AR000206UK01
Trigger Event	PDS Initial Record Created Notification	PRPA_TE000208UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	PDS Birth Notification	PRPA_MT000212UK03

 

6.21    PDS Cross Check Trace Query - QUPA_IN000014UK01

This interaction occurs when a request to trace a patient on the PDS is started, for cross-check purposes. The PDS Query Placer sends a PDS Cross Check Trace Query, with the various patient details, to the PDS Query Fulfiller.

 

Sending Role	PDS Query Placer	QUPA_AR000001UK01
Receiving Role	PDS Query Fulfiller	QUPA_AR000002UK01
Trigger Event	PDS Cross Check Trace Query	QUPA_TE000014UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Query Control Act	QUQI_MT050000UK01
Message Type	PDS Cross Check Trace Query	QUPA_MT000006UK01

 

 

Receiver Responsibilities

Reason	Interaction
Query failed	Query Act Failed: QUQI_IN010000UK14
Query successful	PDS Cross Check Trace Query Response: QUPA_IN000015UK02

 

6.22    PDS Cross Check Trace Query Response - QUPA_IN000015UK02

This interaction occurs when a request to cross-check trace a patient on the PDS results in a successful match. The PDS Query Fulfiller sends a PDS Cross Check Trace Query Response, with a number of data fields relating to the patient or patients, to the PDS Query Placer.

 

Sending Role	PDS Query Fulfiller	QUPA_AR000002UK01
Receiving Role	PDS Query Placer	QUPA_AR000001UK01
Trigger Event	PDS Cross Check Trace Query Response	QUPA_TE000015UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgment Response	QUQI_MT030101UK03
Message Type	PDS Cross Check Trace Query Response	PRPA_MT000213UK02

 

 

 

7    Message Definitions

This section describes each of the message types used amongst the various interactions. For each message type, links are provided to detailed documentation:

• A diagrammatic representation of the message model;
• A table view of each data field used within the message containing detailed guidance on how each field is populated together with examples;
• The schema for the message type;
• One or more example messages conforming to the schema and guidance.

7.1    PDS Simple Trace Query - QUPA_MT000001UK01

 

            

 

Example 1

 

Features of this example include:

• Search on full postcode;
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on family name and first given name.

Example 2

 

Features of this example include:

• Search on PAF Key;
• Search on sex;
• Search on full date of birth;
• Search on family name and first given name.

 

7.2    PDS Advanced Trace Query - QUPA_MT000002UK02

The Advanced Trace supports tracing based on the following parameters:

• Family Name/Surname;

• Given Name/First Name;

• Other Given Name;

• Date of Birth or Date of Birth Range;

• Date of Death or Date of Death range;

• Sex;

• Address Lines 1-5;

• Postcode;

• PAF Key;

• Primary Care Data.

 

The following parameters are also required:

• Historic Data Flag;

• Search Type (Alphanumeric or Algorithmic).

 

 

For Alphanumeric searches the mandatory data items are:

• Family Name/Surname;

• Sex;

• Search Type = 1.

 

The Name details will be compared to all name types (i.e. usual, previous, preferred, alias).

The following details are ignored: name suffix, title, Person Name Classification.

The address details will be compared to all addresses (usual, correspondence, temporary). The Address Association Type if given is not used.

The Alphanumeric search does not cater for misspellings or typographical errors. However, it is possible to use a wildcard character (*) with at least two preceding characters.

Partial postcodes may be used for Alphanumeric searches by using a part of the postcode and a wildcard character (*).
 

For Algorithmic searches the following combinations have been proposed. Note that these may be subject to refinement:
 

1. Family Name/Surname, Given Name/Forename, Date of Birth (or Date of Birth Range).  In this case name transposition will be carried out if no matches are found on the first pass.

 

2. Family Name/Surname, Sex, Date of Birth, Postcode. 

 

3. Given Name/Forename, Sex, Date of Birth, Postcode.

 

4. Family Name/Surname, PAF Key

 

The name details will be compared to all name types (i.e. usual, previous, preferred, alias).

 

The following details are ignored name suffix, title, Person Name Classification. 

 

The address details will be compared to all addresses (usual, correspondence, temporary).  The Address Association Type if given is not used.

 

 

        

 

Example 1

 

 

Features of this example include:

• No historic data required;
• Alphanumeric search required;
• Search on full address;
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on NHS number;
• Search on family name and initial;
• Search on national GP code.

 

Example 2

 

Features of this example include:

• Historic data required;
• Algorithmic search required;
• No address;
• Search on sex;
• Search on date of birth range with partial dates;
• Search on usual family name with initial;
• Search on national GP Practice code.

 

Example 3

 

Features of this example include:

• No historic data required;
• Alphanumeric search required;
• Usual address with a postcode having a wildcard (*);
• Search on sex;
• Search on full date of birth;
• Search on full date of death;
• Search on NHS number;
• Search on  family name and given name, both having wildcards (*);
• Search on national GP Practice code.

 

7.3    PDS Simple Trace Query Response - PRPA_MT000200UK01

Return match after a simple trace search using input parameters.

 

Single match responses are to a high confidence level. Simple Trace can only return a single match.

 

       

 

Example 1

 

Features of this example include:

• Single match to a simple trace query;
• Return of NHS number;
• Return of usual address;
• Return of current telephone numbers;
• Return of current usual name;
• Return of sex;
• Return of full date of birth;
• Return of full date of death;
• Return of death notification status;
• Return of current registered GP Practice.

 

Example 2

 

Features of this example include:

• Single match to a simple trace query;
• Return of NHS number;
• Return of current usual name;
• Return of sensitivity information status (confidentiality code);
• Return of no further details as sensitivity conditions apply.

 

7.4    PDS Advanced Trace Query Response - PRPA_MT000207UK02

Return match after an advanced trace  search using input parameters.

 

Single match responses are to a high confidence level. Matching algorithms will deliver a quantitative matching level and PDS policy may vary on the level required for a trusted match. An advanced trace can return multiple matches.

 

       

 

Example 1

 

Features of this example include:

• Multiple matches to an advanced trace query;
• Returns for first match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of full date of death;

• Return of current registered GP Practice.

• Returns for second match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of current registered GP Practice.

 

Example 2

 

Features of this example include:

• Multiple matches to an advanced trace query;
• Returns for first match are:

• Return of NHS number;

• Return of current usual name;

• Return of sex;

• Return of full date of birth;

• Return of full date of death;

• Return of current registered GP.

• Returns for second match are:

• Return of NHS number;
• Return of current usual name;
• Return of sensitivity information status (confidentiality code);
• Return of full date of birth.

Example 3

 

Features of this example include those found in example 1, plus:

• Source of the patient care provision data;
• System Generated Effective dates for the patient care provision data (for historic data).

 

7.5    PDS Retrieval Query - QUPA_MT000003UK02

A request for patient details to PDS. The retrieval message supports requests for any or all of the retrievable fields. A history flag is used to indicate whether or not historic data is to be returned in addition to current data.

 

       

 

Example 1

 

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve Call Centre Data details only.

 

Example 2

 

Features of this example include:

• Patient identified by NHS number;
• Historic data flag set;
• Retrieve full person demographics.

 

Example 3

 

Features of this example include:

• Patient identified by NHS number;
• Historic data flag set;
• Retrieve proxy details only.

 

Example 4

 

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve current usual name;
• Retrieve date of birth, date of death, sex.

 

Example 5

 

Features of this example include:

• Patient identified by NHS number;
• Historic data flag not set (i.e. no history required);
• Retrieve pharmacy details only.

 

7.6    PDS Retrieval Query Response - PRPA_MT000201UK03

A general class of retrieval message containing the maximum permissible fields able to be retrieved.

 

       

 

Example 1

 

Features of this example include:

• Response to retrieval query 1 above;
• Patient identified by NHS number;
• Retrieval of System Change Number only.

 

Example 2

 

Features of this example include:

• Response to retrieval query 2 above;
• Patient identified by NHS number;
• Retrieval of full person demographics:
  • superceded IDs;
  • usual name;
  • other names;
  • birth date;
  • death date + death notification status;
  • sex;
  • consent details;
  • confidentiality + NHAIS posting details.
• Retrieval of System Change Number (always returned by PDS);

 

Example 3

 

Features of this example include:

• Response to retrieval query 3 above;
• Patient identified by NHS number;
• Retrieval of full proxy details;
• Retrieval of System Change Number (always returned by PDS);

 

Example 4

 

Features of this example include:

• Response to retrieval query 4 above;
• Patient identified by NHS number;
• Retrieval of current usual name;
• Retrieval of date of birth, date of death, sex.
• Retrieval of System Change Number (always returned by PDS).

 

Example 5

 

Features of this example include:

• Response to retrieval query 5 above;
• Patient identified by NHS number;
• Response indicates patient found but no data found.
• Retrieval of System Change Number (always returned by PDS).

 

7.7    PDS Confirm NHS Number Query - QUPA_MT000004UK01

To confirm that the PDS Service User Record for this NHS Number is consistent with the locally-held patient details as indicated by the unique version control number.

 

Note both PDS and NHAIS temporary NHS Numbers may also be used.

 

            

 

 

Features of this example include:

• Patient identified by NHS number.

 

7.8    PDS Confirm NHS Number Query Response - PRPA_MT000202UK02

A positive response to the confirm NHS Number query. A number of PDS data fields are output as part of the response, to reduce the need for additional queries immediately following confirmation.

 

       

                         

Example 1

 

Features of this example include:

• Response to NHS Number Confirmation query 1 above;
• Patient identified by NHS number;
• Usual address returned;
• Usual name returned;
• Sex, date of birth, date of death and death notification status returned
• Current registered GP practice returned;
• Consent details returned;
• System change number returned.

 

Example 2

 

Features of this example include:

• Alternative response to NHS Number Confirmation query 1 above;
• Patient identified by NHS number;
• Limited details returned due to sensitivity conditions applying to the Service User record.

 

7.9    PDS NHS Number Allocation Request - PRPA_MT000203UK03

To make a request on PDS to allocate a NHS Number. The minimum set of data items judged adequate to make a NHS Number allocation will vary according to PDS operational policy.

 

       

 

Example 1

 

Features of this example include:

• Usual address;
• Telephone, mobile and e-mail communications;
• Usual name;
• Sex;
• Full birth date;
• Preferred contact method;
• Preferred written communication format
• Registered GP Practice;
• Preferred language where not English + interpreter required indicator;
• Indication of previous NHS contact;
• NHAIS and NHAIS user as registering authority.
• Additional NHAIS registration information including military service, previous name, and UK residence period.

 

Example 2

 

Features of this example include:

• Usual address;
• Telephone;
• Usual name;
• Sex;
• Full birth date;
• Registered GP Practice;
• Indication of no previous NHS contact;
• PCT as registering authority.

 

7.10    PDS Registration Request Accepted - PRPA_MT000204UK01

The result message contains the NHS Number if the registration request has been successful.

 

        

 

Features of this example include:

• Response to allocate NHS Number Request example 2 above;
• NHS number allocated.

 

7.11    PDS General Update Request - PRPA_MT000206UK03

This update allows modification of all updateable PDS data fields, including consent and death information.

 

This message is for Accredited Systems excluding NHAIS; NHAIS must use the separate NHAIS Update message.

 

     

 

Example 1

 

Features of this example include:

• Examples of altering each type of data that can be altered;
• System Change Number provided in update.

 

  Example 2

 

Features of this example include:

• Examples of adding each type of data that can be added;
• System Change Number provided in update.

 

Example 3

 

Features of this example include:

• Examples of removing each type of data that can be removed;
• System Change Number provided in update.

7.12    PDS Update Request Accepted - PRPA_MT000205UK01

Used in response to a message which updates the PDS to indicate that the update has been successful and provided the nature of that success.

 

           

 

Features of this example include:

• System Change Number returned.

 

7.13    PDS NHAIS Update Request - PRPA_MT000208UK03

This update allows modification of all PDS data fields updatable by the NHAIS system.

 

     

 

Example 1

 

Features of this example include:

• Examples of altering each type of data that can be altered;
• System Change Number provided in update.

 

Example 2

 

Features of this example include:

• Examples of removing each type of data that can be removed;
• System Change Number provided in update.

 

7.14    PDS Batch Trace Query - QUPA_MT000005UK02

This type of trace is to be used for bulk data cleansing purposes, and is designed to trigger either a Cross Check Trace and/or an Advanced Trace to be run on the PDS.

 

Note: The Cross Check Trace is always performed first in 2007-A batching.

 

The Batch Trace supports tracing based on the following parameters for Cross Check Trace:

• NHS Number;

• Family Name/Surname;

• Given Name/First Name;

• Date of Birth.

 

If a new-style NHS number is present, the PDS will perform a Cross Check Trace.  If this Cross Check Trace fails and a new style NHS number is present this number should be omitted and an Advance Trace Query will be performed.

 

The Batch Trace supports tracing based on the following parameters for a refined type of Advanced Trace:

• Full Surname;

• Full Forename;

• Gender;

• Full Date of Birth;

• Date of Death or Date of Death range (optional);

• Post Code (optional);

• PAF Key (optional);

• Address line(s) (optional);

• GP Code or GP Practice Code (optional).

 

        

 

Example 1

 

Features of this example include Batch Tracing based on the following parameters for Cross Check Trace:

• NHS Number

• Family Name/Surname;

• Given Name/First Name;

• Date of Birth

 

Example 2

 

Features of this example include Batch Tracing based on the following parameters for a refined type of Advanced Trace:

• Family Name/Surname;

• Given Name/First Name;

• Gender

• Date of Birth

• Post Code (Optional, when available)

 

Example 3

 

Features of this example include Batch Tracing based on the following parameters for a refined type of Advanced Trace:

• Full Surname

• Full Forename

• Gender (optional)

• Full Date of Birth

• Date of Death or Date of Death range (optional)

• Post Code (optional)

• PAF Key (optional)

• Address line(s) (optional)

• GP Code or GP Practice Code (optional)

 

 

7.15    PDS Batch Trace Query Response - PRPA_MT000209UK01

Return match after a Batch Trace Query, which will be returned as a result of either a Cross Check Trace or Advanced Trace on the PDS.

 

        

 

Example 1

 

Features of this example are based on a match response to a  Batch Query (that used  Cross Check Trace parameters) :

• NHS Number;

• Family Name/Surname;

• Given Name/First Name;

• Date of Birth.

 

Example 2

 

Features of this example are based on a match response to a  Batch Query (that used a refined type of Advanced Trace):

• Family Name/Surname;

• Given Name/First Name;

• Gender;

• Date of Birth;

• Post Code (Optional, when available).

 

Example 3

 

Features of this example are based on a match response to a  Batch Query (that used a refined type of Advanced Trace):

• Full Surname;

• Full Forename;

• Gender (optional);

• Full Date of Birth;

• Date of Death or Date of Death range (optional);

• Post Code (optional);

• PAF Key (optional);

• Address line(s) (optional);

• GP Code or GP Practice Code (optional).

 

 

7.16    PDS Create Initial Record Request - PRPA_MT000211UK03

To make a request on PDS to create a new record, following a birth. This message contains a number of demographic and clinical details about a birth.

 

        

 

Example 1

 

Features of this example include:

• Address;
• Name;
• Sex;
• Full birth date;
• Clinical Information;
• Registered GP Practice of the Mother;

 

Example 2

 

Features of this example include:

• Address;
• Name;
• Sex;
• Full birth date;
• Clinical Information;
• Registered GP Practice of the mother.;

 

7.17    PDS Create Initial Record Request Rejected (Duplicate Found) - PRPA_MT000210UK03

Used when a request to create an initial record on the PDS and allocate an identifier for a patient has been rejected, as one or more duplicate records were found on the PDS.

 

        

7.18    PDS Birth Notification - PRPA_MT000212UK03

To notify other systems of a birth. This message contains a number of demographic and clinical details about a birth.

 

        

 

Example 1

 

Features of this example include:

• Address;
• Name;
• Sex;
• Full birth date;
• Registered GP Practice of the mother with additional detail;

 

Example 2

 

Features of this example include:

• Address;
• Name;
• Sex;
• Full birth date;
• Registered GP Practice of the mother with additional detail;

 

7.19    PDS Cross Check Trace Query - QUPA_MT000006UK01

Search for patient based on a limited set of parameters, for cross-check purposes. The following data items are used in the search algorithm.

• Family Name/Surname;

• Given Name/Forename;

• Date of Birth;

• New style NHS Number.

 

Other search combination is:

• New style NHS Number;

• Date of Birth.

 

The Name details will be compared to all name types (i.e. usual, previous, preferred, alias).

 

 

        

 

Example 1

 

Features of this example include:

 

• Search on full date of birth;
• Search on family name and first given name;
• New style NHS Number.

 

7.20    PDS Cross Check Trace Query Response - PRPA_MT000213UK02

Return match after a Cross Check Trace Query.

 

Single match responses are to a high confidence level.

 

       

 

Example 1

 

Features of this example include:

 

• Return of full date of birth;
• Return on current usual name;
• Return on the New style NHS Number.

 

Example 2

 

Features of this example include:

 

• Return of full date of birth;
• Return of full date and time of death;
• Return on current usual name;
• Return on the New style NHS Number;
• Return of details about the Primary Care Organization responsible for that patient;
• Return on whether there had been previous contact made with the NHS.

 

 

 

8    Glossary of Terms

Data type	The structural format of the data carried in an attribute.
Data type flavour	A subdivision of a particular data type.
NHAIS	National Health Applications & Infrastructure Services.
OID	Object Identifier, a unique identifier e.g. used to identify coding systems.
PAF Key	Postal Address File, a unique numerical key assigned to every delivery location in the UK.
PCT	Primary Care Trust, responsible for primary and community health services within a geographical boundary.
PDS	Personal Demographic Service
SDS	Spine Directory Services
Service User	A person who is registered on the PDS
UUID	Universally Unique Identifier

 

 

 

9    Changes for v4.3

Move the XML Example messages to a subdirectory within the Examples directory.

 

The other changes for this release are listed below:

 

Section	Artefact ID	Details
5.3	QUPA_IN000016UK02	Corrected the hyperlink in the Query Interaction diagram to PDS Confirm NHS Number Query - QUPA_IN000016UK02.
5.7	PRPA_IN000207UK03	Corrected the hyperlink in the Create Initial Record interactions diagram for PRPA_IN000207UK03.
5.8		Changed the name within the Interaction diagram, from "Create Initial Record Interactions" to "Initial Record Created (Birth) Notification interactions" to avoid any confusion with the title within the diagram in section 5.7.
6.1	QUPA_IN000005UK01	Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface.
6.2	QUPA_IN000006UK02	Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface. In the Receiver Responsibilities table renamed QUPA_IN000011UK01 to the correct interaction QUPA_IN000011UK02.
6.3	QUPA_IN000007UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12. Changed column width of table for consistency.
6.4	QUPA_IN000011UK02	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12. Changed column width of table for consistency.
6.5	QUPA_IN000008UK02	Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface. In the Receiver Responsibilities table renamed QUPA_IN000009UK02 to the correct interaction, QUPA_IN000009UK03.
6.6	QUPA_IN000009UK03	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.7	QUPA_IN000016UK02	Fixed issue of the Internal type Identifier is not matching the main Id  (QUPA_IN000016UK01 instead of UK02 version). Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface.
6.8	QUPA_IN000010UK02	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12. .
6.10	PRPA_IN000201UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.12	PRPA_IN000202UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.14	PRPA_IN000209UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.15	QUPA_IN000012UK02	Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface.
6.16	QUPA_IN000013UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12. Changed column width of table for consistency.
6.17	PRPA_IN000205UK03	Fixed issue of the Internal type Identifier is not matching the main Id  (PRPA_IN000205UK02 instead of UK03 version).
6.18	PRPA_IN000206UK01	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.19	PRPA_IN000207UK03	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12. Fixed issue of the Internal type Identifier is not matching the main Id. Fixed issue of the interaction referencing the wrong payload. (PRPA_IN000207UK03 was corrected to include the UK03 version payload, instead of the previous UK02 version of the payload.)
6.21	QUPA_IN000014UK01	Fixed issue about change to payload element name resulting in breakdown of interface QueryControlAct/Query Interface.
6.22	QUPA_IN000015UK02	Fixed versionCode/creationTime in interactions using Application Acknowledgement - MCCI_MT020101UK12.
6.22		Changed column width of table for consistency.
7.2	QUPA_MT000002UK02	Altered the description of Tabular View QUPA_HD000002UK02-NoEdit.htm Person.name.value to include Family name is mandatory for Alphanumeric trace only. For an algorithmic trace it is possible to supply a given name either instead of or in addition to a family name. The guidance on the use of wildcard should state it is for alpha trace only and that there is a limitation as at least two chars must be present.  Corrected typo in Tabular View QUPA_HD000002UK02-NoEdit.htm, for Person.address.value for wildcards.
7.8	PRPA_MT000202UK02	Examples PRPA_EX000202UK02_01.xml and PRPA_EX000202UK02_02.xml referenced the old payload schema version, this has been resolved.
7.9	PRPA_MT000203UK03	Changed hyperlink to PRPA_MT000203UK03.xsd.  Previously this link pointed to the UK02 version. Example PRPA_EX000203UK03_01.xml referenced the old version of CMET, this has been resolved to reference COCT_MT000200UK02.
7.18	PRPA_MT000212UK03	Examples PRPA_EX000212UK03_01.xml and PRPA_EX000212UK03_02.xml referenced the old payload schema version, this has been resolved. For examples PRPA_EX000212UK03_01.xml and PRPA_EX000212UK03_02.xml, changed the id extension of the patient element from "${NAME-NHS-NUMBER}"  to allow the examples to validate. Ammended "country" attribute of "locatedPlaceOfBirth" to include "<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.174" code="1" displayName="England"/>" for example PRPA_EX000212UK03_02.xml, to validate.