Current Day RIS Systems Perform 3 Basic Functions

Functional Specification for RIS

Current day RIS Systems perform 3 basic functions

1. Scheduling (vetting, appointments & reception)

2. Radiology exam completion workflow

3. Reporting workflow.

RIS integrates with the following IT systems :

· PAS (Patient Administration System) for demographics, current location, current responsible consultant/GP

· PACS—to send reports & scheduling information

· Modalities—receives scheduling information from RIS

I. Demographics & ADT Information consistency—All demographics & ADT (Admission Discharge & Transfer information) must be kept up-to-date on all clinical IT systems within any organization. Any demographics update or patient merges on PAS must realtime update RIS systems.

IHE Standards--Patient Information Reconcilliation (PIR) Profile: “PIR handles: unidentified/emergency patient, demographic information updates ( e.g patient name changes (marriage, etc.) , correction of mistakes, ID space mergers). Such changes are reliably propagated to all affected systems, which update all affected data. The result is a complete patient record. “

1. PACS

2. RIS

3. PAS

Must all comply with PIR Profile of IHE.

II. PATIENT BANNER INFORMATION---The patient demographics and ADT information for a patient MUST be consistently displayed on the top demographic banner of any clinical system (PACS, RIS & Ordercomms)---realtime demographics synchronization with PAS is mentioned above. This is hugely important for patient safety & care –ensure that timely communication, ensuring correct ID, timely action can be taken:

a. Name

b. DOB

c. Sex

d. NHS No.

e. PAS No.

f. Current Patient Location

g. Current Responsible Consultant

III. SEARCH CRITERIA FOR A SINGLE PATIENT or GROUP OF PATIENTS: It should be possible to search for a single/group patients using one or any combination of the following criteria:

a. Name

b. DOB

c. Sex

d. NHS No.

e. PAS No.

f. Current Responsible Consultant

g. Requesting Responsible Consultant

h. Current Patient Location

i. Operator

j. Reporter

k. Exam Status of study (see section--)

l. Modality

m. Exam Description

n. Exam Room

o. Date Range (for exams)

IV. CLINICAL METADATA FIELDS ON RIS REPORT: The following clinical information needs to be stored & available for display for the clinical user/Radiologist viewing the radiology report. This also identifies what clinical data fields should be transmitted as metadata fields or tags to XDS registry/repository (if XDS is made the standard for including radiology report into the EPR). The RIS must be capable for creating a HL7 CDA document with the metadata fields described below. The CDA document report should be transferred to PACS for display alongside images and also to EPR, RAS or GP systems.

PATIENT (synchronized with PAS)

Name,

DOB,

Sex,

PAS No.,

NHS No. (when available)

REQUESTER—synchronized with Ordercomms

Name of Requester

Grade of requester

Contact number of requester

Requesting **Responsible Consultant/GP (Team)—(Also RECIPIENT)

Requesting Speciality/Department/GP surgery

Requesting Institution

Date & time of request made

EXAM INFORMATION—synchronized with PACS & modalities

Modality

Exam Description---(National Exam Codes & Descriptions)

Exam Status

Exam Room (where the exam has been performed)

Time when exam completed on modality

OPERATOR/IMAGE CREATOR

Name of Operator

Grade of Operator

Contact number of Operator

Performing Responsible Consultant

Performing Department/Speciality--Radiology

Performing Institution/NHS Trust

REPORT INFORMATION

Name of Reporter

Grade of reporter

Contact number of reporter

Typist (if applicable)

Reporting Responsible Consultant

Reporting Department/Speciality

Reporting Institution/NHS Trust

Date & time report verified

V. RADIOLOGY WORKFLOW STATUS: This is a key concept for driving a workflow within the radiology department. The status must be synchronised between Ordercomms, RIS, PACS & Results Acknowledgement systems.

The below table shows an exam status, system on which this status is created & possible status changes from each of the status

RADIOLOGY WORKFLOW STATUS / STATUS CREATOR / STATUS CHANGE to
1 / Requested / Ordercomms & RIS (if a paper request) / Vetted, Held, Arrived, Appointment booked, DNA, Cancelled, Was not Brought
2 / Vetted / RIS / Held, Appointment Booked, Arrived
3 / Held / RIS / Appointment Booked, Cancelled
4 / Cancelled / Ordercomms & RIS / Acknowledged
5 / Arrived / RIS / Exam performed, Exam Not performed
6 / Did not Attend / RIS / Acknowledged
7 / Appointment Arranged / RIS / Arrived, DNA, Was not Brought
8 / Exam Started (NM exams) / RIS / Exam Completed
9 / Exam Completed / RIS / Report dictated, Unauthorised report, Authorised report
10 / Exam Not performed / RIS / Acknowledged
11 / Report Dictated / RIS / Unauthorised report, Authorised report
12 / Unauthorised Report / RIS / Authorised Report
13 / Authorised Report / RIS / Viewed, Acknowledged, Supplementary Report
14 / Was not Brought / RIS / Acknowledged
15 / Addendum/Supplementary Report / RIS / Viewed, Acknowledged
16 / Viewed / RAS/Ordercomms / Acknowledged, Review Requested
17 / Acknowledged / RAS/Ordercomms / Review Requested, Supplementary Report/addendum
18 / Review Requested / RAS/Ordercomms / Supplementary Report
19 / Housekeeping / RIS / Any appropriate workflow status

VI. EXAM PRIORITY: It should be possible to identify whether an exam is urgent on RIS at every stage of workflow..

1. The urgent priority must be transmitted from Ordercomms. However, it should be possible to change priority at any stage of workflow—

I. vetting,

II. scheduling,

III. reception,

IV. exam completion, &

V. dictation.

2. When a worklist is compiled for vetting, scheduling, exam completion, dictation, or transcription. The urgent priority exams must always come to the top of the worklist.

VII. ELECTRONIC REQUESTING---The following HL7 Data Fields that MUST be transmitted from Ordercomms to RIS for any electronic request made on Ordercomms:

Patient Demographics
Name,
DOB,
Sex,
Address,
PAS No.
NHS No.
Requesting Responsible Consultant/GP
Requesting Speciality/Department/GP Surgery
Requester
Name,
Grade &
Contact no.
Patient Location at Request
Date& time of Request
Priority
Patient Category
Exam Description
Clinical History
Additional Exam specific questions on Ordercomms

Any electronic request sent from Ordercomms must automatically become a “requested status” on RIS.

This information should be transmitted as a HL7 CDA document if the Ordercomms supports HL7 CDA. RIS must be able to display HL7 CDA documents.

VIII. Electronic Request Information Display on RIS

Ideally, the above electronic information should come as a HL7 CDA format which will have a document format easily readable for radiographers & radiologists. RIS must be able to display the following information clearly which is easy to read by radiologists & radiographers even if Ordercomms delivers through a HL7 version2 messaging format.

1. Clinical History

2. Exam Description

3. Priority

4. Requesting Responsible Consultant/GP

5. Requesting Speciality/Department/GP surgery

6. Requester

Name
Grade
Contact Number of Requester

7. Patient Location at Request

8. Patient Category

9. Date of Request

10. Output from Specific Questions based on exam type/location etc asked on Ordercomms (See Section I):

IX. ORDER OUTCOMES on RIS & COMMUNICATION

Every electronic request MUST only have one of the following outcome status on RIS

1. Cancelled in RIS

2. Did Not Attend (DNA)

3. Exam not Performed

4. Authorised/Verified Report

Each of these outcomes MUST be communicated with the requesting team. The reason for “exam not performed” and “cancelled” must populate the report text of the results screen.

DNA, cancellation of order on RIS, exam not performed reason should not require other forms of communication (letter/telephone etc). The form of communication must be the consistent with what is used for communicating a approved/verified report.

A RIS may communicate verified reports/other results with other systems electronically which may include

1. Ordercomms

2. Results Acknowledgement System

3. PACS

4. GP systems

5. PAS/HIS/EPR etc

The “results” sent out from RIS should include the following:

a. Cancelled in RIS with reason

b. Did Not Attend (DNA)

c. Exam not Performed with reason

d. Authorised/Verified Report

This should produce a HL7 CDA document format.

X. PAPER REQUESTING: For paper requests, the above data fields will need to be manually entered by the receptionist/appointments clerk. It should be possible to scan the request card against the episode. The episode should acquire a “requested status” on RIS. (In the same way as any electronic request sent from Ordercomms must automatically become a “requested status” on RIS.) This can then proceed to other status—vetted, arrived, DNA & cancelled.

XI. RADIOLOGY REPORT CONTENT

The Radiology Report once created in the RIS often will be transferred to other Healthcare IT systems (e.g. PACS, EPR, Results Acknowledgement Systems, Ordercomms, Results Reporting Systems, GP systems etc) or maybe printed. It is important that the content of the report is complete, comprehensive and readable. It is important that the report has reached a verified/authorised status before it is transmitted to another IT system. Any addendum/Supplementary report status must automatically transmit to the other IT systems that are fed by RIS.

Patient Demographics
Name,
DOB,
Sex,
Address,
PAS No.,
NHS No.
Requesting Responsible Consultant/GP
Requesting Speciality/Department/GP surgery
Reporter
Name
Grade of Reporter
Contact number for Reporter
Reporting Department/Speciality (Radiology for radiology Reports)
Date & time of Report
Priority---Urgent, Routine
Patient Category---NHS, Private, CatII etc
Exam Description
Workflow Status
Authorised/Verified Report
Amended/Supplementary Report
Acknowledged
Alert Status (see U below)
No alert
Alert
Alert acknowledged
Report text

The report should ideally output as HL7 CDA (Clinical Document Architecture) document. 1-11 describe the machine readable content of report---whilst 12 denotes the human readable content.

XII. NOTEPAD or SCRIBBLER against an exam---There should be a notepad or scribbler function which allows staff to record any free text entry as reminders, MRI protocols or something they wish to document. This mimics from the post-it notes on paper requests, scribbles on the request card, comments box on the request card. The scribbler/notepad should be linked to an exam and be visible on every step of the department workflow.

XIII. VETTING WORKFLOW:

Once an Ordercomms is implemented paper request cards should slowly disappear.

The RIS must be able to perform the vetting functions adequately.

I. Vetting Worklist: This a worklist with status “Requested” It should be possible to create a vetting worklist using 1 or more of these filters:

a. Status—Requested

b. modality,

c. Referring department/Speciality,

d. Responsible Consultant

e. Date range of request

f. Intended Vetter

g. Etc

2. Save favourite filters—it should be possible for users to create & save their favourite filters

3. Change/Cancel Request---At vetting stage a request maybe cancelled on RIS. Through status synchronization the status in Ordercomms & RIS should change to cancelled. The reason for changing or cancelling the Request is documented in RIS. The reason for cancellation must be documented & transmitted as a HL7 document and transmitted to all receiving systems that would normally receive reports. This will allow for appropriate communication to referring teams.

4. Vetting process allows for every request to move from a “requested” status to either have

a. Vetted

b. Cancelled

5. Protocols & Sequences---Currently radiologists use the paper to scribble protocols & sequences on the paper card at the time of vetting or protocolling prior to scan list. These cards which is subsequently available to radiographers at time of scan. It is important that RIS has the functionality to record any protocols or sequences and make this available throughout the workflow in the department in the same way as paper based workflow. A notepad/scribbler function which allows freetext entry maybe a method for protocols to be recorded.

6. Intended Vetter: The default intended vetter should be “general”. However, it should be possible for staff to allocate vetting to certain teams or individuals---musculoskeletal MRI team, Head & Neck team etc

XIV. APPOINTMENTS DIARY: Having a good appointments diary set-up is key to efficiency & accuracy of appointments process. It should be easy to maintain an appointments diary for each of the exam rooms.

1. Create sessions (e.g—morning, afternoon & evening)

2. create timed appointment slots within the sessions

3. It should be possible to “reserve” certain appointments slots for specific needs—for inpatients only, for orthopedic MRI, Head & Neck Cancer MRI. When a receptionist hovers over a reserved slot it should come up with a warning message

4. Ability to allocate a supervising radiologist/operator ( a radiographer/sonographer for barium etc). for sessions.

5. Set-up of appointment diary should be simple & flexible for appointment clerks to manipulate. (e.g Reduce the diary appointment slot if required, double book if requested by radiologist/operator etc) . An IT specialist should not be required for configuring electronic diary.

XV. APPOINTMENT WORKFLOW

It must be possible to create an appointments worklist (containing list of exams with “Vetted Status” or “Requested Status”). Appointments clerk should be able to create a worklist with filters. Some exams may not need vetting, so appointments clerk should be able to arrange appointments without vetting—i.e from a requested status. Other modalities will need exams to be vetted prior to appointments being booked.

1. Appointments Worklist:

a. Status—Vetted Or Requested (or both)

b. Modality

c. Department/Specialty

d. Data range of request

Appointment Clerk must be able to efficiently able to create an appointment for a patient once clicking on the 1st patient on the worklist using the diary functionality:

2. Appointment clerks should be able to save filters as favorites

3. Patient demographics –address, telephone numbers must be available & synchronized with PAS, so that appointments clerk is able to ring patients with ease.

4. System must present all available appointments—from the appointments diary-- for the clerk for them to give the patient a choice.

5. When a list of available appointments are visible to an appointments clerk, the following information should be clearly visible on the list:

a. date and time

b. length of appointment

c. supervising radiologist/radiographer/sonographer (if applicable)

d. relevant information—reserved slot—for inpatients, Head & Neck Cancer MRI etc

6. On booking an appointment it should automatically print out a preconfigured appointments letter with patient demographics, date, time & location of exam and any relevant instructions for the patient (fasting etc)