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

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

  1. 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:
  2. Name
  3. DOB
  4. Sex
  5. NHS No.
  6. PAS No.
  7. Current Patient Location
  8. Current Responsible Consultant
  1. 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:
  2. Name
  3. DOB
  4. Sex
  5. NHS No.
  6. PAS No.
  7. Current Responsible Consultant
  8. Requesting Responsible Consultant
  9. Current Patient Location
  10. Operator
  11. Reporter
  12. Exam Status of study (see section--)
  13. Modality
  14. Exam Description
  15. Exam Room
  16. Date Range (for exams)
  1. 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)

PATIENT (synchronized with PAS)

  1. Name,
  2. DOB,
  3. Sex,
  4. PAS No.,
  5. NHS No. (when available)

REQUESTER—synchronized with Ordercomms

  1. Name of Requester
  2. Grade of requester
  3. Contact number of requester
  4. Requesting **Responsible Consultant/GP (Team)—(Also RECIPIENT)
  5. Requesting Speciality/Department/GP surgery
  6. Requesting Institution
  7. Date & time of request made

EXAM INFORMATION—synchronized with PACS & modalities

  1. Modality
  2. Exam Description---(National Exam Codes & Descriptions)
  3. Exam Status
  4. Exam Room (where the exam has been performed)
  5. Time when exam completed on modality

OPERATOR/IMAGE CREATOR

  1. Name of Operator
  2. Grade of Operator
  3. Contact number of Operator
  4. Performing Responsible Consultant
  5. Performing Department/Speciality--Radiology
  6. Performing Institution/NHS Trust

REPORT INFORMATION

  1. Name of Reporter
  2. Grade of reporter
  3. Contact number of reporter
  4. Reporting Responsible Consultant
  5. Reporting Department/Speciality
  6. Reporting Institution/NHS Trust
  7. Date & time report verified
  1. EXAM 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

EXAM STATUS / STATUS CREATOR / STATUS CHANGE to
1 / Requested / Ordercomms / 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 booked / 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
  1. 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—

  1. vetting,
  2. scheduling,
  3. reception,
  4. exam completion, &
  5. 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.

  1. ELECTRONIC REQUESTING---The following Data Fields that MUST be transmitted from Ordercomms to RIS for any electronic request made on Ordercomms:
  1. Patient Demographics
  2. Name,
  3. DOB,
  4. Sex,
  5. Address,
  6. PAS No.
  7. NHS No.
  8. Requesting Responsible Consultant/GP
  9. Requesting Speciality/Department/GP Surgery
  10. Requester
  11. Name,
  12. Grade &
  13. Contact no.
  14. Patient Location at Request
  15. Date& time of Request
  16. Priority
  17. Patient Category
  18. Exam Description
  19. Clinical History
  20. Additional Exam specific questions on Ordercomms

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

  1. Electronic Request Information Display on RIS

RIS must be able to display this information in a clearly which is easy to read by radiologists

  1. Clinical History
  2. Exam Description
  3. Priority
  4. Requesting Responsible Consultant/GP
  5. Requesting Speciality/Department/GP surgery
  6. Requester
  7. Name
  8. Grade
  9. Contact Number of Requester
  10. Patient Location at Request
  11. Patient Category
  12. Date of Request
  13. Output from Specific Questions based on exam type/location etc asked on Ordercomms (See Section I):
  1. ORDER OUTCOMES on RIS & COMMUNICATION

Every electronic request MUSTonly 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 with other systems electronically which may include

  1. Ordercomms
  2. Results Acknowledgement System
  3. PACS
  4. GP systems etc

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

  1. Cancelled in RIS with reason
  2. Did Not Attend (DNA)
  3. Exam not Performed with reason
  4. Authorised/Verified Report
  1. 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.
  1. 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.
  1. VETTING WORKFLOW:

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

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

  1. Vetting Worklist: This a worklist with status “Requested” It should be possible to create a vetting worklist using 1 or more of these filters:
  1. Status—Requested
  2. modality,
  3. Referring department/Speciality,
  4. Responsible Consultant
  5. Date range of request
  6. Intended Vetter
  7. Etc
  1. Save favourite filters—it should be possible for users to create & save their favourite filters
  1. 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 populate the results field on Ordercomms/Results Acknowledgement system. This will allow for appropriate communication to referring teams.
  2. Vetting process allows for every request to move from a “requested status”to either have
  3. Vetted
  4. 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
  1. 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)

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

  1. Status—Vetted Or Requested (or both)
  2. Modality
  3. Department/Specialty
  4. 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:

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. RIS 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:

  1. date and time
  2. length of appointment
  3. supervising radiologist/radiographer/sonographer (if applicable)
  4. 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)

In the future, it will be possible that patients will request for this letter to be sent electronically to them. Hence, pdf/word type format of such letters must be possible, with capability to attach to e-mails.

5. Once an appointment is made for a patient then exam status change to Appointment booked.

  1. RECEPTIONISTS WORKFLOW: A receptionist is going to verify the ID of the patient, allocate an exam room and change the status to “arrived”. There are 2 type of patients

1. Status requested or vetted---those that will walk in from A&E, wards or clinics. Particularly if a department provides a walk in service for CR, one-stop ultrasound etc. This will be a status of the exam will be “requested”. The reception will allocate a exam room & change status to “arrived”.

2. Status Appointment Booked—Those patients who are already scheduled to have an examination (see section on appointments)—the receptionist will simply change the status to “arrived”

3. Receptionist must be able to able to configure “reception worklist” for

  1. Status—Appointment Booked Or Requested (or both)
  2. Modality (one or multiple)
  3. Exam Rooms (one or multiple)

4. User must be able to save their favourite worklist filters.

5. Paper Request—Receptionist must also be able to accept paper request. Create a requested status for the exam, with a scanned card against the episode & then change to arrived status.

6. Status Change—After dealing with the patient (booked-in or walk-in ) the status will be changed by receptionist to arrived.

  1. DICOM Modality Worklist—When a patient arrives within a department a modality (CT, MR, US etc) needs to be “aware” that the patient is in the department & pull the relevant demographics & study information across to the modality (to avoid manual data entry on the modality). In simplistic terms, DICOM Modality Worklist(DMWL) is a list of patients on RIS who have an “arrived” status. As the scheduling system RIS is responsible for scheduling patients & ensuring logging patients arrival into the department. Each modality will continuously query the RIS (which should provide a DMWL) for any exams –based on modality & Exam Room. Normally the DMWL provider is the scheduling system used for providing scheduling information to a modality(In Radiology RIS provides a DMWL for radiology modalities). The following minimum information needs to be provided by RIS to modalities.
  2. Patient Demographics
  3. Name,
  4. DOB,
  5. Sex,
  6. PAS No.,
  7. Modality
  8. Exam Description---(usually National/Local Exam Codes & Descriptions)
  9. Exam Room
  10. Accession No. (RIS must generate this for every exam)
  11. Study UID (RIS must generate this for every exam)

The modalities query the RIS & display a list of patients--- related to one or more Exam rooms who have “arrived” status. Once the status is changed to “exam performed” or “exam not performed” on RIS,-- the exam should drop off the DMWL and no longer be visible to modalities.

“IHE Standard—Scheduled Workflow Profile--Scheduled Workflow establishes a seamless flow of information that supports efficient patient care workflow in a typical imaging encounter. It specifies transactions that maintain the consistency of patient information from registration through ordering, scheduling, imaging acquisition, storage and viewing.

Modalities (as acquisition modality actor),

RIS (as departmental system scheduler actor),

PACS (as Image Manager & Image display)

must all support to Scheduled Worklfow Profile of IHE”

A standardised approach to DMWL provision is key to supporting long term storage of DICOM images from non-radiology modalities like—cardiology, retinal images etc

Current Situation in NHS--In many hospitals in NHS, PACS Brokers (often called Connectivity Managers, RIS Gateway, PACS Broker etc) provide DMWL functionality. This could be related to the inability of RIS to provide a DMWL or PACS vendors insist on including brokers as part of their PACS solution. However, if a RIS is capable of providing a DMWL there is no need for creating a additional weak link between RIS and modalities--- thus introducing an additional point of failure. Use of PACS Brokers is a non-standard implementation. Hence, PACS replacement is a time for NHS to review their PACS implementations so that they adopt global standards—which are key to ensuring plug & play interoperability & reducing price of NHS IT.

Exceptional circumstances where a PACS broker may be required: If there are 2 or more separate information system scheduling for the same modality—e.g. NBSS & RIS for a mammography modality, Ultrasound modality used for cardiac echoes & radiology i.e.--- scheduled by RIS for radiology & CIS for Cardiac Echoes. Use of brokers should only be on exceptional circumstances.

  1. OPERATORS WORKFLOW: The Operator (Radiographer/Sonographer or Radiologist) will complete an exam and get it ready for reporting—which is the next step.

1. Exam completion worklist must be configurable by the operator:

  1. Status—Arrived or Exam Started (or both)
  2. Exam Room—it should be possible to have a single or multiple exam rooms for shared lists
  3. Modality

It should be possible to save favourite filters for worklistsby users.

2. Status change may either –exam started (for NM), exam completed, exam not performed

3. If exam is not performed then it should be possible to document a reason--- which can be transmitted to the requesting team in the form of a result—whether this be paper or electronic (in the same way as transmitting an authorised report).

4. It must be possible to document the main operator—

a. name of operator

b. grade of operator

c. contact number

(with abilty to document additional operators/student)

5. It must also be possible to allocate reporting to an intended reporter—radiologist or a pool of reporters

6. Exam/Modality Specific Data---it must be possible to create forms/data items to record modality specific data—e.g. radiation exposure, contrast, Buscopan, balloon/stents/catheters, LMP, WHO radiology intervention checklist etc

7. It should be possible to create a “referrer evaluation” report (auto-report) by the operator

8. Operator must be able to review previous exams for the patient and also previous reports.

9. Additional exams—It should be possible for operators to add an additional exams as required.

  1. REPORTING WORKFLOW:

1. Reporting worklist must be configurable by the reporter. It should be possible to save “favourite reporting workists”