Contents

Change History

In Version	Author	Date	Amendment Details
1.0	Core Technical Team	10/05/2004	First Issue
1.1	Core Technical Team	25/06/2004	Added Error Correction section & fixed documentation errors. Corrected spelling error in message models & updated versions
1.2	Core Technical Team	13/08/2004	Changes to align with the Clinical Statement.
1.3	Core Technical Team	03/09/2004	Includes new generic Control Act Wrapper, new SDS OIDs and updated Agent SDS CMETs.
1.4	Core Technical Team	17/09/2004	Changes to align with Clinical Statement.
2.0	Core Technical Team	07/01/2005	Redesign of Diagnostic Imaging Report Message.
2.1	Core Technical Team	17/03/2005	Updates to DI Report in line with change requests
2.2	Core Technical Team	14/06/2005	Updates to DI Report to cater for electronic requesting and minor updates in line with Change Requests. Inclusion of new DI Request message, and guidance on usage of POC for DI Requesting Encounter and DI Fulfilling Encounter
2.3	Core Technical Team	30/09/2005	Guidance notes added to section 7.3 and 7.4.  The use of any DI message within a POC 'Care Event Report' message is currently under development, being revised against changes to the POC message.
2.4	Core Technical Team	28/02/2006	Point to point messaging. New Artefact naming format. New DI Request Withdraw interaction. DI messages used within a POC 'Care Event Report' message have been removed from this release. DI Report Withdrawal Interaction references the Notify Message Withdrawal with Reason - UKCI_MT000001UK01.
2.5	Core Technical Team	09/05/2006	Address Issues raised by Accenture, including a new section 1.2 to highlight point to point messaging, and an improved tabular view description of the ED datatype used by the ProcedureReportSegment act.
2.6	Core Technical Team	08/08/2006	Changed reference to the infrastructure Withdrawal to new version.
2.7	Core Technical Team	22/03/2007	Relocated XML Example files..

 

 

 

1    Overview

Diagnostic Imaging (DI) covers the requesting of DI procedures, DI department encounters, and DI reports in response to requests.  In this version of the Message Implementation Manual the DI messages will NOT go to PSIS (please refer to section 1.2) in this release.

 

DI covers the following image producing modalities: -

• Computer Aided Tomography  - CT

• Magnetic Resonance Imaging  - MRI

• Thermal Imaging

• Nuclear Medicine (Radio-isotope Imaging) - NM

• Ultrasound - US

• X-Ray

 

Each 'DI Request' will be for one or more DI Procedures of a single modality - Multiple modality requests are not supported. Each 'DI Report' and DI department encounter may be multi-modality.

 

The scope of the current release covers manual and electronic DI Requests, and electronic DI Reports in response to DI Requests from Primary Care and Secondary Care Out-Patients.

 

N.B. There is a possibility that the Choose & Book processes may be used to book an appointment for one or more DI Procedures known to require them. In order to facilitate this without significant change to the current design, the Unique Booking Reference Number, UBRN will be optionally included within the DI Request communication specification.

 

All DI Requests are sent directly from the request Placer to the intended DI Fulfiller.

 

All DI Reports are sent to identified Primary Information Recipients (primarily the requesting GP).  They may also be copied to other HCPs for information using the 'Tracker' mechanism.

 

It is assumed that a DI Procedure will be completed or aborted prior to a report on it being issued. Provision is made for reporting on requests where all procedures are not complete and a later report is issued when all procedures have been completed.

 

There may be more than one report issued in fulfilment of a single request, each report being complete in its own right.

 

Where incomplete reports are issued, the final report will replace them in their entirety. This is achieved by a 'Replacement' message where the new complete report replaces the previous report.

 

1.1    Error Correction

The following messages in this domain may be withdrawn using the Generic Withdrawal message Notify Message Withdrawal UKCI_MT010101UK02 as defined in the Infrastructure Domain. The use case is where a message is sent with an incorrect NHS Number.

 

DI Request

DI Report

 

 

1.2    DI Messages will not go to PSIS in this release.

 

The DI report and request messages will only be point to point, and will NOT go to PSIS in this release.  As such, they:-

 

• Do NOT need to provide a PSIS Focal act or Event.

• Do NOT need to carry CRE Types.

• Must have an II in the Focal Act to facilitate whole message replacement.

• ActRefs that use replacement relationships to update acts through the use of snapshot IDs are not required.

• Cardinalities of those acts that used snapshot IDs previously, and where the cardinality of the ID was 2..2 have been changed to 1..2 (to reflect the use of the local identifier, as mandatory ID, with the possibility of the global ID being used in the future.

• In general, a more up to date act can replace another without need for an explicit replacementOf relation, where the new act is just messaged with the same id and updated fields.  Therefore, the replacementOf.ActRef has been removed off the FulfillerRequest in the DI Report.

 

 

 

2    Storyboards

2.1    Scenario 1 - Covering all processes from 'DI Request' to 'DI Report'

2.1.1    Part 1 - The GP/OP DI Request

Jane Robinson (NHS No. 9900002857) goes to see her GP, Dr Dickenson at Mirfield Surgery on the 27th February 2005. On arrival at the surgeries Drop-in clinic, at approximately 1040 am, she is taken into see Dr Justin Case, the locum who has been asked to cover the session as everyone else is ill.

 

Dr. Case chooses Janes name off his work-to-do list (or patients-to-be-seen, etc). This opens the Care Event details function of the clinical application. Dr Case first looks at Jane's previous history on his local system which is not yet fully NPfIT compliant. He notices that Jane has recently been started on treatment for osteoporosis. Dr Case asks why Jane has come to the surgery today. Jane explains that she has 3 problems which have been giving her some trouble. The first is that she has very severe headaches in the morning which are not relieved with analgesia. These pains have been getting worse in the last week and she is getting dizzy spells. The second problem is that she has been having quite painful flooding during her menstrual cycle and sometimes some blood in her urine. The final problem is that she has been having irregular bouts of diarrhoea with no associated vomiting.

 

Dr Case asks Jane for some more information about her first problem:

 

Dr Cases Questions	Janes Answers
Have you had a head injury recently?	Yes I passed out on the way home from a party in the pub 3 weeks ago and when I woke up I had a headache and had cut my scalp. My hair was matted with blood.
How much had you had to drink on that occasion?	I cant remember but I admit I was feeling quite drunk
Did you go to the hospital?	No
Do you drink often?	No
Where on your head do you get the pains?	Across my forehead and down the right side over my ear where the cut is

 

Dr Case examines Janes head and finds that there is still a noticeable lump on the right side, where the scalp was cut. He decides to send Jane for a skull x-ray to see if there is any evidence of a fracture.

 

Dr Case then asks Jane about her second problem:

 

Dr Cases Questions	Janes Answers
How long have you been having this flooding?	Up until last month, just once a month. Since then it has been every week.
How bad has the pain been on these occasions?	Much more severe than Im used to
Where do you generally get the pains?	Mainly around my stomach, but sometimes it is slightly lower
Do you have any discharge when you get these pains?	No
How often do you pass water?	Once or twice a day
Do you get pain when you pass water?	No
How do you feel?	I feel weaker than usual especially as the day goes on.
When you are not menstruating do you still notice the blood in your urine?	Yes

 

Dr Case then asks Jane about her third problem:

 

Dr Cases Questions	Janes Answers
How long have you been having the diarrhoea?	Once or twice a week since Xmas
Have you changed you eating habits?	No, I eat a staple diet regularly
Have you been caught short by this?	Not yet
Do you take anything for it?	Imodium from the pharmacy
Does it work for you?	Yes
How do you feel?	OK. Its just an annoyance.

 

 

Dr Case examines Janes abdomen at this time. He finds that it is not tense/rigid and that the organs (liver & spleen) appear normal. He decides that he needs to arrange an Ultrasound Scan of her abdomen & pelvis.

 

Dr Case explains that he is sending Jane for some DI investigations at York DGH and that one of them will probably be an appointment. He asks Jane when she would prefer to have the appointment and she answers before Easter (Good Friday being the 25th March 2005). He then asks her to go and provide a sample of urine. Whilst Jane is doing this Dr Case opens his requesting module and completes the various prompted fields in the electronic request screen that is presented to him.

 

Note: How the application prompts/collects the answers to any required questions (patient administration/modality specific) is entirely down to the application developers.

 

Jane reappears with the urine sample which Dr. Case then tests with a DipStix. He finds that the urine tests positive for blood and enters this information onto the request details.

 

Dr Case knows that he will not be working at Mirfield Surgery when, after the DI Reports and the blood tests have been returned, Jane is likely to attend next. He identifies Dr Dickenson as being the person to whom the DI Reports need to be sent. He also identifies for the Ultrasound request Janes requirement for a car to take her to and from the anticipated appointment. As Janes abdominal symptoms and her age put her in a potential at risk group for bowel cancer, Dr Case also identifies Mr Cutit, the surgeon, as a recipient of a copy of the DI Report of the Ultrasound procedures. This would act as a heads-up to the local Cancer Care Group should the result indicate this condition.

 

Dr Case closes his requesting module and is informed that the application has created 3 requests from the entered data with request numbers MS0501234 (General X-ray) & MS0501235 (US). It asks him if he wants the tokens printed and he answers Yes.

 

He presents Jane with the 2 DI Request tokens each representing one separate DI Request that his actions have generated. He explains to her that the Ultrasound Scans will be an appointment and that she will receive it in the post direct from the Ultrasound Department. He tells Jane that she can take the other token into the X-Ray department any week day between the hours of 9am and 5pm. Jane leaves the surgery at approximately 11.00 am.

 

2.1.2    Part 2 - The DI Report communication

Dr De Darke has finished reviewing the images from the Skull X-ray and the 2 CT Head scan procedures. He dictates the report for each procedure onto analogue tape, identifying on the PACS worklist that the each report has been done. This action moves the procedure listings onto that of the Medical Secretarys. He then takes the tape to the one designated for the hot desk.

 

This secretary loads the tape into her player and selects the first reported procedure from the worklist. This opens the reporting application on the RIS. She selects Dr De Darke as the author of the report from a drop-down list. This opens the reporting screen and she types the report onto the system. After typing the report the system asks her if the report needs verification to which she replies Yes. This places the procedure listing back into Dr De Darkes worklist. The secretary does this for each of the 3 procedures.

 

Dr De Darke is waiting for the images from the patient after Jane Robinson and notices that the reports have been typed. He selects the first procedure from the worklist and this opens the report text screen. He reads the report and is asked to verify the content. As the text is correct he replies yes. He is then presented on screen with a drop-down menu for the urgency of the report. This determines how quickly the communication is dispatched to the intended recipient(s). He selects urgent .He then performs the same actions for the other 2 reports.

 

As all 3 procedures are portions of the same request and there are no outstanding procedures to be performed, reported or verified, the RIS now assumes the request to be fulfilled and proceeds to formulate the DI Report communication.

 

Once completed the RIS sends out the DI Report communication according to the instructions received in the request and the urgency status.

 

A short while later Mirfield Surgery receives the DI Report communication. As the communication is urgent and Dr Dickenson (the intended recipient) hasnt logged on, the system copies it to the next responsible clinician (in descending order) identified in the workgroup listing. As everyone else is not available it appears in Dr Cases inbox with an urgency flag.

 

Dr Case reads the report and annotates Jane Robinsons local record as necessary.

 

Note: 

1. Jane Robinson is now in new Provision of Care event which began when she was booked into A&E. This event and its outcome is not part of this documentation. 
2. Dr Cases annotations are not part of this documentation

 

2.2    A DI Report message containing multiple DI Procedure Reports

 

Ellen Smith goes to see her GP, Dr Fixit at Mirfield Surgery. She is still having problems with her chest and now has swelling of her right ankle. Additionally she has been experiencing some heart burn and lower abdominal pain.

 

Dr Fixit asks her some questions and then examines her chest, abdomen and ankle. He explains that the ankle swelling is just a result of her heart tablets but he will need to keep an eye on it. As Ellen seems to be running a slightly raised temperature he suspects that she is suffering from a chest infection.

 

Dr Fixit decides that Ellen needs to have a Chest and Abdomen X-ray. He writes a request form out and hands it to Ellen to take with her to the X-ray Department.

 

Ellen goes along to the local X-ray department at York DGH and hands in her request form. The receptionist enters her details onto the RIS using the local codes CXR (Chest) and AXR (Abdomen). The RIS gives the request the local ID of 04Y0119986G. Mrs Givem Rads, the radiographer, then performs the procedures.

 

On viewing the images, Mrs Rads decides that she cant see anything that needs immediate attention and sends Ellen home.

 

Later that evening Dr Indiana Jones, the radiologist, views the images created in the procedures and reports on the procedures individually. The reports are dictated onto tape and left to be transcribed in the morning.

 

The next morning the secretary types up Ellen Smiths procedure reports onto the RIS and then moves onto the next patients report.

[N.B. This X-ray Department local policy is that only special examination (MRI, CT NM & US) reports need to be verified by the reporting radiologist before they are sent out to the requestor]. Because of this, the secretarys action of moving onto the next patients report acts as the trigger to send the completed report out to Dr Fixit. The system in this instance becomes the author of the message.

 

Note:   In creating the DI Report message, the local system translates any local codes, where it can, into nationally agreed alternatives. Hence:

• CXR becomes 67632007
• AXR becomes 60654006

 

At lunchtime Dr Fixit starts his afternoon surgery and checks his local system for any new diagnostic reports on his patients. (His system automatically posts the incoming reports to his system mailbox).

 

He sees that there is a DI Report for Mrs Smith waiting for him to view. He clicks on it and the local system shows that it contains 2 separate reports one for each procedure. He opens the report for the Chest X-ray and reads it. He then opens and reads the report for the Abdomen X-ray.

 

2.3    Scenario 3 - A DI Report message containing a DI Summary Report with multiple DI Procedure Reports

 

Wilfred Smith goes to the Swan Medical Centre to see his GP, Dr. Percy Sugden.

 

He tells Dr. Sugden that for several days now he hasnt been able to move his left elbow and has pain in his wrist. Additionally he has noticed some bruising on his left shoulder. Dr. Sugden asks him if he has had a fall. Wilfred cant remember having done so.

 

On examination the doctor finds that Wilfreds shoulder movement is badly impaired as is his elbow and wrist.

 

A couple of X-ray examinations are in order, so Dr. Sugden fills out an electronic request for X-ray examination on Wilfreds left upper arm to include shoulder and elbow. His system has given this request the ID = SMCS234567. He gives Wilfred the token representing the request and asks him to go to the local X-ray Department at York DGH.

 

On arrival at the X-ray Department, Wilfreds token is accepted by the IRMER radiographer and the details are retrieved from the RIS. The RIS gives the request the local ID of 04Y0125678G. The individual procedures are identified by their local codes of SHRL and ELBL.

 

Wilfred is taken into an X-Ray room and his left shoulder and elbow procedures are done separately by the radiographer, Marie Curie, using the PACS system. She identifies the examination code for each procedure before acquiring the images. This separates the procedures on the PACS archive. When Marie views the images she sees that Wilfred has a fracture of the Humeral head and another of the Radial Head in his elbow. She performs a few extra views of each joint and then asks Wilfred to sit outside whilst she shows the films to the Radiologist.

 

Dr Glowin de Darke, the Radiologist, reports the procedures onto digital tape, separately as he sees them on the PACS workstation. Whilst these injuries are not uncommon, they are rarely found together on the same patient from the same incident so he decides to do a Summary report to suggest to the GP that Wilfred may have had several falls recently and that he should probably be referred to the Care of the Elderly team for further investigation if A&E do not do so.

 

The medical secretary sees that the reports have been completed and types them up. The individual examination reports are typed into the PACS system and the Overview into the RIS.

 

Marie in the meantime has taken Wilfred around to A&E so that the Orthopaedic team can assess him for treatment of his fractures. The A&E Department are able to view the PACS images and reports as well as the RIS reports.

 

Even though Wilfred is in A&E the reports are automatically sent to Dr Sugden for his information because the RIS system finalises the report without verification due to local policy and this is the trigger event to send it out to the requestor.

 

Note: 

• The PACS system does not allow clinicians from outside the DGH to access images
• In creating the DI Report message, the local system translates any local codes, where it can, into nationally agreed alternatives. Hence:
  • SHRL becomes 29592009 (Shoulder X-ray) + 272741003 (Laterality) +7771000 (Left)
  • ELBL becomes 18747005 (Elbow X-ray) + 272741003 (Laterality) + 7771000 (Left)

 

Dr Sugden, a short time later sees that a report for Mr Smith has arrived. He clicks on it and the local system opens the report allowing him to read the text of the Radiologists interpretation.

 

2.4    Scenario 4 - A DI Report message containing a single DI Procedure Report for multiple DI Procedure Instances

 

Bernard Jones, a known Pagets disease sufferer, goes to see his GP, Dr Cantankerous at the Swan Medical Centre.

 

This is a regular yearly check-up. As it is the 5^th check-up since his last set of investigations, Dr Cantankerous decides he wants to have a limited series of imaging performed on Bernard called a Skeletal Survey. He discusses the option with Bernard who agrees. Dr Cantankerous then checks with his acceptable radiographic requesting list (supplied by the X-ray Department as part of an on-going IRMER initiative) to see what Survey he needs to request. The list identifies a Limited Skeletal Survey (Lateral Skull, PA Chest, AP Pelvis and Lateral Left Femur) as being the one to request for Pagets disease.

 

Dr Cantankerous completes an electronic request form and generates the token that represents it. The system has given this request the ID = SMC234789. He gives the token to Bernard.

 

Bernard goes to the X-Ray Department at York DGH. On arrival at the X-ray Department, Bernards request form is accepted by the IRMER radiographer and even though the request asks for a Limited Skeletal Survey this is entered onto the RIS as its component procedures of skull, chest, pelvis and left femur, with a request ID of 04Y0126783G.

 

Bernard is taken into an X-Ray room and has his procedures done. These are acquired separately by the radiographer, Amy Curry, using the PACS system. She identifies the examination code for each procedure before acquiring the images. This separates the procedures on the PACS archive. When Amy views the resultant images she sees that they are within quality control parameters and that there is nothing on them to suggest Bernard will need to be treated immediately. Amy then sends Bernard home.

 

Dr Hannah Gordon, the Radiologist, reviews the images from all the procedures and reports them collectively as a Skeletal Survey directly onto the RIS (i.e. types the report herself), entering the request ID (04Y0126783G). After indicating that Dr Gordon was the reporting radiologist, she then types the report into the system.

 

Once she has finished typing Hannah types YES into the verified window on the reporting screen and then moves onto reporting the next patients images.

The RIS having finalized Bernards report with verification, treats this as the trigger event to send the completed report out to the requestor.

 

Note:

• The PACS system does not allow clinicians from outside the DGH to access images
• In creating the DI Report message, the local system translates any local codes, where it can, into nationally agreed alternatives. Hence:
  • SXR becomes 55965002
  • CXR becomes  67632007
  • PEL (pelvis X-ray) becomes 268425006
  • FEML becomes  241075002 (femur x-ray)+ 272741003 (laterality) + 7771000 (left)

 

Dr Cantankerous, a short time later sees that a report for Mr Jones has arrived. He clicks on it and the local system opens the report allowing him to read the text of the Radiologists interpretation.

 

3    Application Roles

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

 

 

3.1    DI Request Placer - POII_AR000001UK01

The role of the DI Request Placer is to initiate the Diagnostic Imaging Requests to the DI Fulfiller.

 

DI Request Placer Interactions

 

3.2    DI Fulfiller - POII_AR000003UK01

The role of the DI Fulfiller is to carry out the requested procedures, or suitable substitute, and produce a report on the findings. Once the report has been produced, and Verified if required, it is sent to a DI Report Receiver. The Primary Recipient of the Report is the system of the Healthcare Professional (HCP) with clinical responsibility for the patient.

 

DI Fulfiller Interactions

 

 

3.3    DI Report Receiver - POII_AR000004UK01

The DI Report Receiver is the Primary recipient system of the DI Report message. As the Primary Receiver, the system shall make the report available to the identified HCP who has a duty to take any clinical action required based on the content of the report(s) contained within the message. There may only be one Primary Recipient.

 

DI Report Receiver Interactions

 

 

3.4    DI Report Tracker - POII_AR000005UK01

The DI Report Tracker is a secondary recipient system of the DI Report. As a secondary receiver, the DI Report Tracker shall make the report(s) available to the identified HCP. The HCP does not have any specific clinical responsibility to respond to the content of the message. The HCP receiving the copy report may take action as appropriate or as requested in the content of the report.

 

DI Report Tracker Interactions

 

 

 

4    Trigger Events

4.1    DI Request Release - POII_TE000001UK01

The Trigger Event for the sending of a DI Request is the decision to send a completed DI electronic request.

Structured Name	DI Request Release
Type	State-transition Based

 

4.2    DI Report Release POII_TE000002UK01

The Trigger Event for the sending of a DI Report is the 'authorisation for release'.  This may be:

1. post completion of the transcription of the report which corresponds with the Automated Release decision point on the Business Process Model.   Note:  The report could be sent out as either 'verified' or 'unverified'

    

2. post verification of a previously transcribed report. This corresponds with the Release Report decision point on the Business Process Model.  Note:   In this case the report can only be sent out as 'verified'

The report may be 'completed' or still 'active'. Reports that are sent with a status of 'active' are incomplete, and indicate that a further 'completed' report is intended to be sent to replace it at a later date. Completion may be of one or more DI Procedure Reports within the same request, a single report for two or more DI Procedures Instances within the same request, or, a single DI Summary Report for one or many DI Procedure Reports.

 

Structured Name	DI Report Release
Type	State-transition Based

 

4.3    DI Report Withdraw POII_TE000003UK01

The Trigger Event for the sending of a Withdraw DI Report is the decision to withdraw a report that has been sent out.  This shall be sent to any recipient irrespective of being the Primary recipient or a 'Tracker'.

 

Structured Name	DI Report Withdraw
Type	State-transition Based

 

4.4    DI Request Withdraw POII_TE000004UK01

The Trigger Event for the sending of a Withdraw DI Request is the decision to withdraw a request that has been sent out.  This shall be sent to any recipient irrespective of being the Fulfiller or a 'Tracker'.

 

Structured Name	DI Request Withdraw
Type	State-transition Based

 

4.5    DI Report Complete POII_TE000005UK01

The Trigger Event for the sending of a DI Report is the 'authorisation for release'.  This may be:

1. post completion of the transcription of the report which corresponds with the Automated Release decision point on the Business Process Model.   Note:  The report would be sent as  'verified'

    

2. post verification of a previously transcribed report. This corresponds with the Release Report decision point on the Business Process Model.  Note:   In this case the report can only be sent out as 'verified'

The report shall be 'completed'.  Receipt of a 'Completed' report does not exclude receipt of a replacement 'Completed' report at a later date.

 

Structured Name	DI Report Complete
Type	State-transition Based

 

4.6    DI Report Corrected POII_TE000006UK01

The Trigger Event in the DI Fulfiller system caused by 'correcting', amending or appending a previously completed and sent report.  This may be:

1. post completion of the transcription of the report which corresponds with the Automated Release decision point on the Business Process Model.   Note:  The report would be sent as 'verified'

    

2. post verification of a previously transcribed report. This corresponds with the Release Report decision point on the Business Process Model.  Note:   In this case the report can only be sent out as 'verified'

The report shall be 'corrected'.  Receipt of a 'Corrected' report does not exclude receipt of a replacement 'Corrected' report at a later date.

 

Structured Name	DI Report Corrected
Type	State-transition Based

 

4.7    DI Report Reject POII_TE000007UK01

This trigger indicates the report has been received, has been deemed invalid by the receiving application and has been rejected.  The receiver can only reject the report, if the contained receiver details, DI Request details or the patient details are incorrect. They cannot reject if they don't like the content of the report.

 

Structured Name	DI Report Reject
Type	State-transition Based

 

4.8    DI Report Confirm POII_TE000008UK01

This trigger indicates acceptance of a report event.  It indicates this report is accepted by the receiving application as processable, and provides a means of a positive transaction acknowledgement.

 

Structured Name	DI Report Confirm
Type	State-transition Based

 

 

 

5    Interaction Diagrams

5.1    DI Request Interactions

 

5.2    DI Report Interactions

 

6    Interactions

6.1    DI Request - POII_IN000001UK01

This interaction is between the DI Request Placer and the DI Fulfiller

Sending Role	DI Request Placer	POII_AR000001UK01
Receiving Role	DI Fulfiller	POII_AR000003UK01
Trigger Event	DI Request Release	POII_TE000001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Request	POII_MT000001UK01

Receiver Responsibilities

Reason	Interaction
DI Fulfiller Acknowledges Receipt Status (Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.2    DI Result Report - POII_IN000003UK01

This interaction is between the DI Fulfiller and the DI Report Receiver (i.e. the Primary Recipient)

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Receiver	POII_AR000004UK01
Trigger Event	DI Report Completion	POII_TE000002UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Receiver Acknowledges Receipt Status(Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.3    DI Report Inform - POII_IN000004UK01

This interaction is between the DI Fulfiller and the DI Report Tracker (i.e. copy recipient)

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Tracker	POII_AR000005UK01
Trigger Event	DI Report Release	POII_TE000002UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Tracker Acknowledges Receipt Status(Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.4    DI Report Withdrawal for Report Receiver- POII_IN000005UK01

This interaction is between the DI Fulfiller and the DI Report Receiver. Its use case is where a Report has been sent for an incorrect patient. See Infrastructure for the Generic Message Definition

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Receiver	POII_AR000004UK01
Trigger Event	DI Report Withdraw	POII_TE000003UK01
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
DI Receiver Acknowledges Receipt Status (Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.5    DI Report Withdrawal for Report Tracker- POII_IN000006UK01

This interaction is between the DI Fulfiller and the DI Report Tracker. Its use case is where a Report has been sent for an incorrect patient. See Infrastructure for the Generic Message Definition

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Tracker	POII_AR000005UK01
Trigger Event	DI Report Withdraw	POII_TE000003UK01
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
DI Report Tracker Acknowledges Receipt Status (Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.6    DI Request Withdrawal for DI Fulfiller- POII_IN000007UK01

This interaction is between the DI Request Placer and the DI Fulfiller. Its use case is where a Request has been sent for an incorrect patient. See Infrastructure for the Generic Message Definition

 

Sending Role	DI Request Placer	POII_AR000001UK01
Receiving Role	DI Fulfiller	POII_AR000003UK01
Trigger Event	DI Request Withdraw	POII_TE000004UK01
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
DI Report Fulfiller Acknowledges Receipt Status(Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.7    DI Report Complete For Report Receiver- POII_IN000008UK01

This interaction is for a Completed DI Report (with Receiver Responsibilities) for the Report Receiver.  This interaction signals completion of the report as well as the DI Fulfiller's Promise for the report.

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Receiver	POII_AR000004UK01
Trigger Event	DI Report Complete	POII_TE000005UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Receiver confirms receipt of DI Report Complete	POII_IN000013UK01
DI Report Receiver rejects receipt of DI Report Complete	POII_IN000012UK01

 

 

6.8    DI Report Complete For Report Tracker- POII_IN000009UK01

This interaction is for a Completed DI Report (with Receiver Responsibilities) for the Report Tracker.  This interaction signals completion of the report as well as the DI Fulfiller's Promise for the report.

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Tracker	POII_AR000005UK01
Trigger Event	DI Report Complete	POII_TE000005UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Tracker confirms receipt of DI Report Complete	POII_IN000013UK01

 

 

6.9    DI Report Corrected For Report Receiver- POII_IN000010UK01

This interaction is used when the DI Fulfiller has corrected, amended or appended a previously completed and sent DI Report, for the Report Receiver.  It signals the correction of the report as well as the DI Fulfiller's promise for the report.

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Receiver	POII_AR000004UK01
Trigger Event	DI Report Corrected	POII_TE000006UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Receiver confirms receipt of DI Report Corrected	POII_IN000013UK01
DI Report Receiver rejects receipt of DI Report Corrected	POII_IN000012UK01

 

 

6.10    DI Report Corrected For Report Tracker- POII_IN000011UK01

This interaction is used when the DI Fulfiller has corrected, amended or appended a previously completed and sent DI Report, for the Report Tracker.  It signals the correction of the report as well as the DI Fulfiller's promise for the report.

 

Sending Role	DI Fulfiller	POII_AR000003UK01
Receiving Role	DI Report Tracker	POII_AR000005UK01
Trigger Event	DI Report Corrected	POII_TE000006UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Receiver confirms receipt of DI Report Corrected	POII_IN000013UK01

 

 

6.11    DI Report Reject Response - POII_IN000012UK01

This interaction is a Report Reject Response. This is used by the receiver to confirm rejection of a result.

 

Sending Role	DI Report Receiver	POII_AR000004UK01
Receiving Role	DI Report Fulfiller	POII_AR000003UK01
Trigger Event	DI Report Reject	POII_TE000007UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Fulfiller Acknowledges Receipt Status(Application Acknowledgement)	MCCI_IN010000UK13

 

 

6.12    DI Report Confirm Response - POII_IN000013UK01

This interaction is a Report Reject Response. This is used by the receiver to confirm rejection of a result.

 

Sending Role	DI Report Receiver	POII_AR000004UK01
Receiving Role	DI Report Fulfiller	POII_AR000003UK01
Trigger Event	DI Report Confirm	POII_TE000008UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	DI Report	POII_MT000002UK01

 

 

Receiver Responsibilities

Reason	Interaction
DI Report Fulfiller Acknowledges Receipt Status(Application Acknowledgement)	MCCI_IN010000UK13

 

 

 

 

7    Message Definitions

7.1    DI Request - POII_MT000001UK01

A message containing the requesting of one or more diagnostic imaging procedures from within a single diagnostic imaging modality.

     

7.1.1    Scenario 1 - Part 1 example 1

A 'DI Request' message containing a request for a single X-ray.

7.1.2    Scenario 1 - Part 1 example 2

A 'DI Request' message containing a request for Ultrasound procedures.

 

7.2    DI Report - POII_MT000002UK01

A message containing the Radiological interpretation of one or more diagnostic images, obtained as a result of one or more DI Procedure Instances carried out in response to a DI Request.

 

     

 

7.2.1    Scenario 1 - Part 4 example

A 'DI Report' message containing reports for a single X-ray and 2 CT Scans.

 

7.2.2    Scenario 2 example

A DI Report message containing multiple DI Procedure reports.

7.2.3    Scenario 3 example.

A DI Report message containing a DI Summary report with multiple DI Procedure reports.

7.2.4    Scenario 4 example.

A DI Report message containing a single DI Procedure Report for multiple DI Procedure Instances.

 

 

8    Glossary of Terms

DI	Diagnostic Imaging.
RIS	Radiology Information System./td>
PACS	Picture Archive & Communications System.
Placer Request	A request to a Diagnostic Imaging department for work to be carried out.
Fulfiller Request	A request made onto a RIS in response to a Placer Request. There may be more than one Fulfiller request created in response to a single Placer Request.
Procedure Report	A report on one or more completed (or aborted) procedures. Procedure Reports reference instances of DI Procedures
Summary Report	A report which summarises previously reported Procedures. Summary Reports reference Procedure Reports.
DI Request Release	The trigger point where it is decided to send a DI Request upon completion of a completed DI electronic request.
DI Report Release	The trigger point where a DI Report has been authorised for release from the RIS. Note:   A released report may be 'unverified'.
Verified Report	A transcribed report that has been checked and approved as a second step prior to release. Note: The 'Verifier' may not always be the same person as the 'Author' of the report.
Unique Booking Reference Number (UBRN)	The unique reference number created by the Choose & Book system. It is used by Choose & Book to link requests for Service to a Referral Letter (possibly including a DI Request) to an appointment slot at a chosen Service Provider. The Service Provider can use the UBRN to check/amend the status of a booking made on the Choose & Book.

 

 

9    Report Status

When a DI Report message is sent from a DI Fulfiller to the DI Report Receiver (or Tracker), there are a number of Acts within the message which have a status that is conveyed between the two systems.

 

Each Fulfiller Request for DI Procedures is created on the Fulfiller system. As each DI Procedure is carried out, it will move from being active to completed. Procedures may also be aborted before completion and a report issued indicating this.

 

Procedures are reported upon when completed but there may be instances where an interim report is 'released' before completion of all the procedures on a request. The initial report may be followed by further Interim report(s) before a final (completed) report is released. When all reports satisfying a Request have been completed, the Request itself shall be fulfilled and completed.

 

Where a final Procedure Report is issued when all procedures have been completed, the status of the report shall be completed and the statues of the procedures shall be completed (or aborted). This shall allow the Fulfiller Request to be completed in fulfilment of the original placer request.

 

 

Act	Status Options
DI Report	active, completed
DI Procedure	completed, aborted
Fulfiller Request Details	active, completed

 

9.1    Storyboards

Guidance on the status of various acts in the 'DI Report' message is provided below for Scenarios 2, 3 and 4.

9.1.1    Scenario 2

 

A single request for one modality for multiple DI Procedures is booked onto the RIS.

The procedures are carried out and completed. A single report for multiple-procedures is transcribed & verified.

A single message is generated where the following are set:

 

Act	Status Options
DI Report	completed
DI Procedure 1	completed
DI Procedure 2	completed
Fulfiller Request Details	completed

 

 

9.1.2    Scenario 3

 

A single request for two DI Procedures in one modality is booked onto the RIS.

The first procedure is carried out and completed. A report is transcribed & verified. The intention is that this is an interim report which shall be replaced by a further report containing both DI Procedure reports

 

A first message is generated where the following are set:

 

Act	Status Options
DI Report	active
DI Procedure 1	completed
Fulfiller Request Details	active
Replacement of	Not included

 

The second DI Procedure is carried out and completed. A report is transcribed & verified.

A second message is generated where the following are set:

 

Act	Status Options
DI Report	completed
DI Procedures 1 & 2	completed
Fulfiller Request Details	completed
Replacement of (for every clinical statement in the message)	References each Previous Clinical Statement act ID. Metadata/status for those acts shall be set to obsolete.

 

 

9.1.3    Scenario 4

 

A single request for two DI Procedures in one modality is booked onto the RIS.

The first procedure is carried out. A report for this procedure is transcribed & verified. The intention is that there are two DI Report messages, each containing a single procedure report segment for one procedure, which fulfil the request

 

A first message is generated where the following are set:

 

Act	Status Options
DI Report	completed
DI Procedure 1	completed
Fulfiller Request Details	active
Replacement of	Not included

 

The second DI Procedure is carried out and completed. A report for this procedure is transcribed & verified.

A second message is generated where the following are set:

 

Act	Status Options
DI Report	completed
DI Procedure 2	completed
Fulfiller Request Details	completed
Replacement of	Not included

 

Both individual reports are valid, complete and together they satisfy the Fulfiller Request.

 

In this case, the previous report shall NOT be overwritten. There are two valid reports in fulfilment of the Fulfiller Request. Neither report requires the other for interpretation but the request requires that both are read to fulfil the request.

 

9.2    Status Management

In any message instance, the following conditions may occur:

 

9.2.1    Completed Request

 

Act	Status	Condition
FulfillerRequestDetails	completed	The DI Report shall be completed, and all Procedures shall be completed (or aborted).
		Implication is that all the reports that will be issued against the request are completed. The Placer should be able to mark their request as completed.

 

 

9.2.2    Completed Report on an Incomplete Request

 

Act	Status	Condition
FulfillerRequestDetails	active	Fulfiller Request has not yet been completed
DIReport	completed	All Procedures in this report shall be completed (or aborted)
		Implication is that there will be another report on the request as the request has not been fulfilled but the report included in the message is complete and shall not be overwritten within the recipient system by the next report against this request. Recipient systems shall associate the two complete DI Reports when received to show all reports for that request.

 

9.2.3    Interim Report on an Incomplete Request

 

Act	Status	Condition
FulfillerRequestDetails	active	Fulfiller Request has not yet been completed
DIReport	active	All Procedures must be completed (or aborted)
		Implication is that the report is Interim, and will be replaced by a completed report at a later date. All the Procedures in this message instance are completed. As the Report is not completed, the request cannot be completed. A later report will replace the current report and will include all the information in the one being replaced in addition to the new report segments and additional completed procedures.

 

 

9.2.4    Invalid conditions

In any message instance, the following may NOT occur:

 

Act	Status	Condition
FulfillerRequestDetails	completed	Fulfiller Request has not yet been completed
DIReport	active	Invalid status DI Report SHALL be completed if Fulfiller Request is complete

 

 

Act	Status	Condition
FulfillerRequestDetails	completed	Fulfiller Request is completed
DIReport	completed	DI Report SHALL be completed if Fulfiller Request is completed
DIProcedures	active	Invalid status Procedures may not be active on a completed Request. They SHALL be completed or aborted.