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

a. PACSb. RISc. PASMust all comply with PIR Profile of IHE.

2. 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)---real-time 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. Nameb. DOBc. Sexd. NHS No.e. PAS No.f. Current Patient Locationg. Current Responsible Consultant

3. 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. Nameb. DOBc. Sexd. NHS No.e. PAS No.f. Current Responsible Consultantg. Requesting Responsible Consultanth. Current Patient Locationi. Operatorj. Reporterk. Exam Status of study (see section--)l. Modalitym. Exam Descriptionn. Exam Room

o. Date Range (for exams)

4. RIS REPORT CONTENT & METADATA---CDA (Clinical Document Architecture) of HL7: A CDA document has 2 parts—a machine processable header in xml & a human readable narrative as the body with some coded elements . Radiology reports fit this global standard of clinical document architecture. Defining the machine processable header information, is key to the concepts of interoperability between clinical IT systems to ensure that reports created in RIS can be transported to stored & displayed by other IT systems like GP systems, PACS & Results Acknowledgement Systems. CDA header information also defines the XDS metatdata tags which is key to the concepts of incorporating radiology reports into a vendor neutral EPR using XDS as the standard.

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.

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.

A. HEADER INFORMATION

a. PATIENT (synchronized with PAS)

i. Name, ii. DOB,

iii. Sex, iv. Addressv. PAS No.,vi. NHS No. (when available)

b. REQUESTER/RECIPIENT—synchronized with Ordercommsi. Name of Requesterii. Grade of requesteriii. Contact number of requesteriv. Requesting Responsible Consultant/GP (Team)v. Requesting Speciality/Department/GP surgeryvi. Requesting Institution

c. DOCUMENT INFORMATION—synchronized with PACS & modalities i. DOC TYPE---Radiology Reportii. Modality iii. Exam Description---(National Exam Codes & Descriptions)iv. Exam Room (where the exam has been performed)--Wherev. Time when report was authorised--When

d. REPORTER/SENDER INFORMATIONi. Name of Reporterii. Grade of reporteriii. Contact number of reporteriv. Typist (if applicable)v. Reporting Responsible Consultantvi. Reporting Department/Specialityvii. Reporting Institution/NHS Trust

B. BODYFree text narrative of the radiology opinion forms the body of the CDA document

C. CODED DATA (others)

a. OPERATOR/IMAGE CREATORi. Name of Operatorii. Grade of Operatoriii. Contact number of Operatoriv. Performing Responsible Consultantv. Performing Department/Speciality--Radiologyvi. Performing Institution/NHS Trust

b. WORKFLOW INFORMATIONi. Workflow Status (See section 5)ii. Workflow Priority (See section 6)iii. Workflow Alert Status

c. Patient Category (NHS, Private or Cat 2) d. Radiation dose—(Temporary field until there is wide adoption of REM profile)

5. 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, Cancelled4 Cancelled Ordercomms & RIS Acknowledged5 Arrived RIS Exam performed, Exam Not

performed6 Did not Attend RIS Acknowledged7 Appointment Arranged RIS Arrived, DNA, Was not Brought8 Exam Started (NM exams) RIS Exam Completed9 Exam Completed RIS Report dictated, Unauthorised

report, Authorised report10 Exam Not performed RIS Acknowledged11 Report Dictated RIS Unauthorised report, Authorised

report12 Unauthorised Report RIS Authorised Report13 Authorised Report RIS Viewed, Acknowledged,

Supplementary Report14 Was not Brought RIS Acknowledged15 Addendum/Supplementary

ReportRIS Viewed, Acknowledged

16 Viewed RAS/Ordercomms Acknowledged, Review Requested17 Acknowledged RAS/Ordercomms Review Requested, Supplementary

Report/addendum18 Review Requested RAS/Ordercomms Supplementary Report19 Housekeeping RIS Any appropriate workflow status

6. WORKFLOW PRIORITY : It should be possible to identify whether an exam is urgent or routine on RIS at every stage of workflow..

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

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

7. ELECTRONIC REQUESTING---The following HL7 Data Fields that MUST be transmitted from Ordercomms to RIS for any electronic request made on Ordercomms. Ideally, this information should also be transmitted as a HL7 CDA document. RIS must be able to display HL7 CDA Request sent from Ordercomms.

a. Patient Demographics i. Name, ii. DOB,iii. Sex,iv. Address, v. PAS No. vi. NHS No.

b. Requesting Responsible Consultant/GP c. Requesting Speciality/Department/GP Surgeryd. Requester

i. Name, ii. Grade & iii. Contact no.

e. Patient Location at Request f. Date& time of Requestg. Priority h. Patient Category i. Exam Descriptionj. Clinical Historyk. Additional Exam specific questions on Ordercomms

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

8. Electronic Request Information Display on RISIdeally, 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.

a) Clinical Historyb) Exam Descriptionc) Priorityd) Requesting Responsible Consultant/GPe) Requesting Speciality/Department/GP surgeryf) Requester

a. Nameb. Gradec. Contact Number of Requester

g) Patient Location at Requesth) Patient Categoryi) Date of Requestj) Output from Specific Questions based on exam type/location etc asked on

Ordercomms :

9. ORDER OUTCOMES on RIS & COMMUNICATIONEvery electronic request MUST only have one of the following outcome status on RIS

a) Cancelled in RISb) Did Not Attend (DNA)c) Exam not Performedd) 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

a. Ordercommsb. Results Acknowledgement Systemc. PACSd. GP systemse. PAS/HIS/EPR etc

This should produce a HL7 CDA document format.

10. PAPER REQUESTING: For paper requests, the RIS 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.

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

12. VETTING WORKFLOW: Once an Ordercomms is implemented paper request cards should slowly disappear. The RIS must be able to perform the vetting functions adequately.

a. Vetting Worklist: This a worklist with status “Requested” It should be possible to create a vetting worklist using 1 or more of these filters:i. Status—Requestedii. modality, iii. Referring department/Speciality, iv. Responsible Consultant v. Date range of requestvi. Intended Vettervii. Etc

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

c. 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.d. Vetting process allows for every request to move from a “requested” status to either have

a. Vetted b. Cancelled

e. 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.f. 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

13. 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.a. Create sessions (e.g—morning, afternoon & evening)b. create timed appointment slots within the sessionsc. 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 d. Ability to allocate a supervising radiologist/operator ( a radiographer/sonographer for barium etc). for sessions.e. 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.

14. APPOINTMENT WORKFLOWIt 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.a. Appointments Worklist:

I. Status—Vetted Or Requested (or both)II. Modality

III. Department/SpecialtyIV. 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:b. Appointment clerks should be able to save filters as favoritesc. Patient demographics –address, telephone numbers must be available & synchronized with PAS, so that appointments clerk is able to ring patients with ease.d. System must present all available appointments—from the appointments diary-- for the clerk for them to give the patient a choice.e. When a list of available appointments are visible to an appointments clerk, the following information should be clearly visible on the list:

i. date and timeii. length of appointmentiii. supervising radiologist/radiographer/sonographer (if applicable)iv. relevant information—reserved slot—for inpatients, Head & Neck Cancer

MRI etcf. 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.g. Once an appointment is made for a patient then exam status change to Appointment booked.

15. 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 patientsa. 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”. b. 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”c. Receptionist must be able to able to configure “reception worklist” for

i. Status—Appointment Booked Or Requested or Vetted (or all 3)ii. Modality (one or multiple)iii. Exam Rooms (one or multiple)

d. User must be able to save their favourite worklist filters.e. 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.f. Status Change—After dealing with the patient (booked-in or walk-in ) the status will be changed by receptionist to arrived.

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

a. Patient Demographicsi. Name, ii. DOB, iii. Sex, iv. PAS No.,

b. Modality c. Exam Description---(usually National/Local Exam Codes & Descriptions)d. Exam Roome. Accession No. (RIS must generate this for every exam)f. 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.

17. OPERATORS WORKFLOW: The Operator (Radiographer/Sonographer or Radiologist) will complete an exam and get it ready for reporting—which is the next step. a. Exam completion worklist must be configurable by the operator:

i. Status—Arrived or Exam Started (or both)ii. Exam Room—it should be possible to have a single or multiple exam

rooms for shared listsiii. Modality

It should be possible to save favourite filters for worklists by users.b. Status change may either –exam started (for NM), exam completed, exam not performedd. 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).e. It must be possible to document the main operator—

a. name of operatorb. grade of operatorc. contact number

(with abilty to document additional operators/student)f. It must also be possible to allocate reporting to an intended reporter—radiologist or a pool of reportersg. 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 etch. It should be possible to create a “referrer evaluation” report (auto-report) by the operatori. Operator must be able to review previous exams for the patient and also previous reports.j. Additional exams—It should be possible for operators to add an additional exams as required.

18. REPORTING WORKFLOW: a. WORKLIST FILTERS: Reporting worklist must be configurable by the reporter. It should be possible to save “favourite reporting workists”

i. Status—exam completedii. Intended Reporter—it should be possible to include a single or multiple

intended reportersiii. Modality (1 or more)iv. Exam Room (1 or more)v. Date rangevi. Patient Location—A&E, Inpatient, Outpatient, GPvii. Specialty/Department

b. STATUS CHANGE—The status change should be from exam completed to dictated, authorized, or unauthorized.c. It should be possible for the reporter to use any of the following methods for reporting depending on circumstances:

i. Typing a report (e.g. on-call/urgent report)ii. Dictation a report (integrated DD)iii. Voice recognition (integrated VR—maybe an optional extra)

d. A list of previous exams for the patient must be visible on the RIS reporting screen. It should be possible to open previous reports with 1 mouse click.e. It should be possible to change the status” to “report dictated” (for DD) or “authorised/unauthorised” for VR/Typed reports.f. With a single mouse click/microphone button click/keyboard stroke the reporter must be able to move to the next exam on the worklist OR be able to recompile the worklist which excludes dictated work (this is a important when using shared work pools)g. Desktop Integration/Context Synchronization between RIS & PACS---There must be automatic Context synchronization with PACS. When an exam is taken up for reporting the relevant images should automatically be displayed on the middle PACS monitor for reporting (right hand monitor is for displaying the relevant priors). Images on PACS must close when the reporter moves to the next exam for reporting or goes back to the worklist.h. If an exam is taken up by a reporter, then the exam should be “locked”. Hence, should not be possible to for another reporter to report on the exam.i. For dictation workflow, the “next exam” or “return to worklist” should work from digital dictation microphone buttons.j. Request Information display : The CDA document of the request/scanned request card must be displayed for reporting (additional mouse clicks should not be required)k. Three CLICK REPORTING WORKFLOW: 3 click reporting workflow should be possible from the RIS & PACS integration.

i. Draw up a RIS worklist for reportingii. Launch a patient’s exam for reporting on RIS—automatic display of

images on PACS with automatic display of relevant prior---dictate/VR a report on RISl. Click on the next exam on RIS worklist—which closes the previous PACS images & launches the next patient on RIS & PACS

19. TRANSCRIPTION WORKFLOW: a. WORKLIST FILTERS: Transcription worklist must be configurable by the transcriptionistStatus—report dictated

i. Reporter—it should be possible to include a single or multiple reportersii. Modality (1 or more)iii. Date rangeiv. Patient Location—A&E, Inpatient, Outpatient, GPv. Specialty/Department

b. STATUS CHANGE: It should be possible to change the status from “report dictated” to “authorised” or “unauthorised” after the report is typed.c. A list of previous exams for the patient must be visible on the RIS screen. It should be possible to open previous reports with 1 mouse click.

d. With a single mouse click/footpedal click/keyboard stroke the transcriptionist must be able to move to the next exam on the worklist or be able to recompile the worklist which excludes typed work (this is a important when using shared work pools)e. if a reporter is using a transcription worklist for VR, the desk-top integration with PACS must work.f. If an exam is taken up by a typist, then the exam should be “locked”. Hence, should not be possible to for another typist to type on the exam.g. It should be possible to save “favourite transcription workist filter”

20. AUTHORIZATION WORKFLOW: a. WORKLIST FILTERS: Authorization worklist must be configurable by the user. It should be possible to save “favourite workists”

i. Status—unauthorisedii. Reporteriii. Modality (1 or more)iv. Exam Room (1 or more)v. Date rangevi. Patient Location—A&E, Inpatient, Outpatient, GPvii. Specialty/Department

b. STATUS CHANGE--It should be possible to change the status from “unauthorised” to “authorised” or “after the report is typedc. Desktop Integration with PACS must be possible at the time of authorization.

21. SUPPLEMENTARY REPORT/MDTM WORKFLOW: : It should be possible for radiologists/reporter to create supplementary reports or document 2nd opinions following discussions at MDTMs or when they review an already reported image.

a. Requests for 2nd opinions may come electronically from Ordercomms, e-mail, discussions, telephone, or part of an MDTM workflow etc. b. STATUS CHANGE---It should be possible to change status from “authorized report”, “viewed report” or “acknowledged report” TO “review requested”. When a review is requested, then it must required for the person requesting a review to identify the intended reporter.c. WORKLIST FILTERS--By marking reports as “review requested” it should be possible to create a MDTM worklist using the following filters

i. status –review requestedii. Intended reporter

d. The system should allow for 2nd opinions to be documented via dictation, typed or via VR. The name of radiologist/reporter should be documented with a date time stamp. The original report must always remain visible at the bottom of the supplementary information. It should be possible to document 2nd opinions or reviews made at MDTM –“reviewed at MDTM” with name of reviewer & date & time of review.e. There should be a context link to display PACS images from the episode/report.

22. PREVIOUSLY ACCESSED RECORDS: A user should be able to review the last 20 previously accessed records, if they realize they have made an error or made an omission whilst reporting, or performing another task etc.

23. ELECTRONIC PATIENT RECORD---Radiology reports must become part of a wider clinical record (Electronic Record). With next generation RIS it is important that we move away from a radiology data silo & make radiology reports a part of the holistic patient record. Adoption of global standards is key to this concept:

a. RIS must act as an XDS/XDS-I source actor of Cross Enterprise Document Sharing Profile-Imaging of IHE

b. RIS must act as XDS &XDS-I Consumer actor of Cross Enterprise Document Sharing Profile-Imaging of IHE. This will allow viewing of other clinical documents/images that are registered on XDS registry (will allow an EPR view of the patient record)

Adoption of XDS by RIS will allow radiologists & other clinical users access to integrated view of ALL clinical doc & images-ECG, Medical photographs, radiology images, Discharge summaries, through an viewer that is XDS consumer compliant.

IHE Standard--Cross Enterprise document sharing for Imaging—XDS-I--- Sharing imaging documents between radiology departments, private physicians, clinics, long term care, acute care with different clinical IT systems & thus make it possible for radiology images to become part of the patient’s EPR.

24. AUDIT DATA:

It is important that the following data. Date time stamp for each status change must be available for audit purposes. It must be easy to output audit data to products which handle report data ---excel spreadsheet, business objects etc

Following audit data is important:a) number of exams of a modality per room per session/week/year (KH12 returns

requires—number of exams per modality per year) b) patient arrival in department to exam completion for different modalities, exam room,

etc.c) Exam completed to dictatedd) Dictated to unauthorisede) Unauthorised to authorised f) Waiting list stats (from data of request to date of exam completed)g) Workload stats for users—operators, reporters etch) any other data field that is captured on RIS should be able to produce auditable data.

25. SINGLE SIGN-ON (SSO) & DESKTOP INTEGRATION (DTI) OR CONTEXT SYNCHRONIZATION—

SSO-Process of logging in should be quick & slick. The system should support single sign-on process as used in a hospital. As a minimum, additional user name and password should not be required when using RIS & PACS. When a user logs into RIS for reporting the user credentials must be passed onto PACS with no need for additional user name and password input.

Desktop Integration (DTI) must be at EXAM level with Information Systems: Desktop Integration with RIS is well established with PACS.

a. Automatic RIS to PACS Integration. In most NHS Trusts RIS is used for reporting of radiology images. For efficiency reasons there should be automatic display of relevant radiology images when an exam is picked up for reporting on RIS (described above)

b. Manual PACS to RIS integration—when images are displayed on PACS, it should be able to display the RIS for that episode. This would be important at MDTMs, or when a request is made for a 2nd opinion etc, to allow for an addendum to be recorded on RIS.

Context Linking with Other systems: There will be a requirement to have a context link with other systems –Ordercomms & Results Reporting systems, Clinical Letter Management System, etc. There needs to be clarity on how context links will be created and also the cost.

26. TESTING & TRAINING SYSTEM: There should be a separate test & training system which is separate from the live environment. This should act as a test-bed for integration/testing new feature prior to roll out into live environment

For training—a) There should be an e-learning tool provided. The system should be

intuitive enough so as require minimal training.b) Separate test system available for training (so that training does not need to

be performed on a live system)

27. TABLES/ MASTER LIST CONCEPT:When buying a RIS it is important to ask suppliers tables/lists for the following entities.

a) Patient list (with demographics—name, age, sex, address, PAS no, NHS no)

b) Responsible Consultant/GP Listc) Department/Speciality Listd) Patient Location Liste) Requester List (name, grade, speciality)f) Reporter List (name, grade & speciality)g) Exam Description or codeh) Exam Status List

PAS should hold the master list for a) Patient List (demographics—name, age, sex, address, PAS no, NHS

no)b) Responsible Consultant/GP Listc) Department/Speciality Listd) Patient Location List

RIS should hold the master lista) Exam Description or code (National codes usually)b) Exam Status List

ACTIVE DIRECTORY or similar IT Directory could be used for keeping an updated/active list of

a. Hospital Users should hold a master list of all hospital staff with grade & speciality. i. subgroup of this list will form the Requester List in Ordercomms (based on the grade of the staff). ii. Another subgroup of this will form the RIS Users:Reporter List in RIS (based on the grade of staff)Operator ListTranscriptionist ListReceptionist ListAppointment Staff Listc. PACS Users etc

iii. Patient Location iv. Department/Specialityv. Responsible Consultant List

If the RIS holds a separate table or list for the above entities, then it is important that these automatically synchronise with master lists or Active Directory for these entities. NB: If there is no automatic synchronization between these lists with the master lists, there

will be a lot of time consuming housekeeping due to duplicate entries into the different systems.

28. CONSISTENCY IN NAMING OF DATA FIELDS—There should be consistency in naming of the following data fields in Ordercomms, RIS, PAS

& PACS (in fact in all Clinical IT systems). This would avoid ambiguity and confusion for the user community.

a) Requesterb) Grade of Requesterc) Requesting Responsible Consultant/GPd) Current Responsible Consultant/GPe) Patient Location at Requestf) Current Patient Locationg) Date of Requesth) Date of Exam*i) Date of Reportj) Patient Categoryk) Exam Description*l) Workflow Status*m) Reportern) Grade of Reportero) Clinical Historyp) Patient Location Types (Inpatient, Outpatients, GP etc)q) Requesting Departmentr) Reporting Departments) Priority

*Where there is a overlap of data field use in radiology & pathology—the term “Investigation” maybe more appropriate rather than “Exam”.

29. WORKFLOW ALERTS for UNEXPECTED/CRITICAL RADIOLOGY REPORTThe radiology department may find a unexpected or a critical report which they may wish to alert the requester. With paper based processes, it is important to pick up the telephone and alert the requesting team/Ward. However, from a Healthcare IT perspective, the RIS MUST be capable of creating an alert. Once the alert is created in RIS must be possible transfer to other Healthcare IT systems used for alerting and acknowledgement -- Results Acknowledgement Systems, GP systems & Electronic White Boards on wards. These alerts must be treated as temporary alerts for the Referring Team to read the reports as a matter of priority. It is important that these alerts are “turned off”, once the report has an acknowledged status. The results acknowledgement system must be capable of informing the RIS and other systems of the acknowledged status.WorkflowAlert Status:

i. No alertii. Alert iii. Alert acknowledged

30. LOCAL CONFIGURATION OF USER ROLES- User roles should be defined locally based on tasks performed:

a. Vettingb. Booking appointmentsc. receptiond. Exam completione. Dictationf. Typingg. System Administration

31. SUPPORT, BUSINESS CONTINUITY & DISASTER RECOVERYa. Support

i. 24/7 supportii. 1 phone number to calliii. Dedicated team of qualified engineers receiving call with ability to

directly deal with any issueiv. On-line tracking of issues raisedv. Transparency on response time to type of support calls vi. Remote & on-site support capabilities

b. Business Continuity & Disaster Recovery: there should be no need for a planned or unplanned downtime. Business continuity should be aimed for. There should be a disaster recovery plan identified in the contract

32. AUDIT TRAILS/VIEW LOG—every time a patient’s data is accessed by a user. This should be logged and the “view log” should be accessible to any user to see. This will remind users that their data access is logged & thus improve patient confidentiality. Any changes made to a record –status change, record update, report update must have a full audit trail of the changes made, or record access.

“Electronic records are supported by audit trails, which record details of all additions, changes, deletions and viewings. Typically, the audit trail will include information on:

■■ who – identification of the person creating, changing or viewing the record;

■■ what – details of the data entry or what was viewed;

■■ when – date and time of the data entry or viewing; and

■■ where – the location where the data entry or viewing occurred. “

DH guidance—“Records Mangement Code of Practice Part 2 (2nd Edition)

33. REMOTE REPORTING & ON-CALL: Remote working is no longer limited to private teleradiology companies. Increasingly NHS Trusts are encouraging radiologists to do on-call from home (as this is more cost-effective for a tax funded health service). Whilst on-call radiologists MUST be able to report from home. A verified report on PACS prevents needs of verbal reports documented on paper notes, and mis-understandings, and thus improving patient care & safety. In the future we will see some radiologists requesting for part working from home. Access to RIS with DD/VR must be available to radiologists working from home. As a minimum, radiologists must be able to simply be able to type from home.

a. Access to other information--Request cards, scanned doc, clinic letters etc b. Access to radiology images on PACS from home. 

34. USER GROUP MEETINGS & PRODUCT DEVELOPMENT during contract lifetime:

a. The customers must have input into future system design/ functionality updates. The supplier MUST have a vibrant user group including an electronic forum (with both clinical users & system administrators involved) which suggests & votes on product enhancement features. A product developer must contribute to user group discussions.b. There MUST be a rolling agenda for product enhancement during the 10year contract. How many product development days will be allocated for every year for every NHS Trust that contracts with the RIS supplier must be defined at the start of the contract period. c. Clarity on how will the next upgrade version of the product be rolled out. (customers must make sure there isn't a charge for software upgrade & that it is built into the revenue expenditure)d. A product developer must be present at the User Group meetings and involved in the electronic discussions, to have an honest dialogue between users & suppliers about what enhancement suggestions are viable for the supplier.

35. REPORT RETENTION: Radiology Reports must be kept as a permanent record as per DH guidance of record Management. Look at Data Retention requirements from DOH.

36. RADIATION DOSE---It is important that radiology departments are able to monitor doses to an individual patient, group of patients (e.g. children, women,) specific modality,

specific exam type etc--- to compare with national averages/standards. Currently radiation dose information is entered in RIS manually. In future, once modalities are able to pass this information directly to PACS, manual recording on RIS will not be required.

IHE Standards: “Radiation Exposure Monitoring (REM) facilitates the collection and distribution of information about estimated patient radiation exposure resulting from imaging procedures. The REM Profile requires imaging modalities to export radiation exposure details in a standard format. Radiation reporting systems can either query for these "dose objects" periodically from an archive, or receive them directly from the modalities.”

Modalities (as Acquisition modality actor) PACS (as Image Manager actor)Must support Radiation Exposure Monitoring Profile of IHE.

In future RIS will not be required to capture this data. Support of IHE will allow feeding of such information into a national radiation monitoring registry for NHS in the future.

Current situation in the NHS: Currently radiation dose information is entered in RIS manually. Support of this profile will provide more accurate information as there wont be any errors related to manual data entry into RIS & will also improve efficient working for radiographers who will no longer be required to enter that data manually.

37. RIS & ORDERCOMMS CONTEXT LINK: There should be a CONTEXT LINK between RIS and Ordercomms, which will allow radiology staff to open Ordercomms to the relevant patient through a button/icon on the top tool bar of RIS.

38. PORTERING-SYSTEM SUPPORT--It should be possible to transmit appointments for inpatients to 3rd party portering system. The following information must be transmitted to Portering system.

a. Patient Demographicsi. Name, ii. DOB, iii. Sex, iv. PAS No.,

b. Modality c. Exam Description---(usually National/Local Exam Codes & Descriptions)d. Exam Room

39. ACCESS & CONTRIBUTION TO XDS BASED EPR:RIS must be XDS/XDS-I source & XDS/XDS-I consumer actors for XDS & XDS-I profile of IHE.Adoption of XDS by RIS will allow radiologists & other clinical users access to integrated view of ALL clinical doc & images-ECG, Medical photographs, radiology images, Discharge summaries, through an viewer that is XDS consumer compliant.

IHE Standard--Cross Enterprise document sharing for Imaging—XDS-I--- Sharing imaging documents between radiology departments, private physicians, clinics, long term

care, acute care with different clinical IT systems & thus make it possible for radiology images to become part of the patient’s EPR.

40. HOUSEKEEPING WORKFLOW: A. Electronic Orders Housekeeping

1. The following lists must be synchronised between PAS, RIS & Ordercomms (Section on Tables & Master Lists)

i. Patient list (with demographics—name, age, sex, address, PAS no, NHS no)

ii. Responsible Consultant/GP Listiii. Department/Speciality Listiv. Patient Location Listv. Requester List (name & grade)

vi. Reporter List (name & grade)vii. Exam Description or code

viii. Exam Status ListIf an electronic request has an message element which exist on a list in Ordercomms but does not exist on RIS, the Order will not proceed on RIS (Example a new location or new consultant has been created and put into the Ordercomms list but not on the RIS list). These should move to a Housekeeping status on RIS. Hence, it is important that these lists are kept automatically synchronised by both RIS & Ordercomms suppliers.2.There maybe a failure of the interface between Ordercomms & RIS when Orders will not proceed to RIS. There must be a mechanism to alert the Systems Manager when the interface has failed.

B. Issues like ---"no images on PACS", request card not scanned in (RIS issue), wrong side labelled (PACS) , CXR looking like dextrocardia when it should not be. (PACS) , Incorrect RIS exam code used--eg. wrist instead of hand (RIS) , CXR labelled as abdo & abdo as chest (RIS) , Sonographer sheet not scanned in & put in for radiologist to report. (RIS) etc are often detected by radiologists at time of reporting. It should be possible to change the workflow status to “housekeeping”. They should be able to free-text document a reason for putting the exam on the housekeeping worklist on the notepad/scribbler.C. It should be possible for admin staff to draw up a worklist with status “housekeeping”.D. Sort out the problem and put it back to the appropriate workflow status.

41. RADIOLOGY REPORT & REQUEST DISPLAY (HL7 CDA display support): Radiology Report & Radiology Request are documents which are created in clinical systems—RIS for radiology report & Ordercomms for radiology requests. The emerging global document standard for clinical documents is HL7 CDA (Clinical Document Architecture) & is being adopted by NHS. PACS must be able to display radiology reports & requests as CDA documents which are transmitted to it. Radiology images, requests & reports must always be linked together (in the same way as the traditional film packets in NHS contained both these documents.) With 1 mouse click these linked documents must be displayed along with the images.Displayable Reports (DRPT) Profile of IHE: manages creation and distribution of “display ready” (PDF or CDA) clinical reports from the creating application, to the department, and to the enterprise.RIS must be a report creator & manager actors for Displayable Report Profile (with option of report repository) 

Compiled by Dr. Neelam DugarConsultant RadiologistDoncaster & Bassetlaw Hospital NHS TrustChairman of RCR Imaging Informatics Group14/4/11Acknowledgements to Mrs. Maxine Clarke (PACS Manager at Norwich), Mr Scott Gill (PACS Manager at Doncaster & Bassetlaw Hospitals) & members of the RCR Imaging informatics Group (as much of the content arises from the forum discussions)

APPENDIX 1IHE Specifications for RIS1. RIS must be an Department System Scheduler actor for PIR profile of IHEPatient 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.”

2. RIS must conform to Department System Scheduler actor for SWF profile of IHEScheduled 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.

3. RIS must be XDS/XDS-I source & XDS/XDS-I consumer actors for XDS & XDS-I profile of IHE.Adoption of XDS by RIS will allow radiologists & other clinical users access to integrated view of ALL clinical doc & images-ECG, Medical photographs, radiology images, Discharge summaries, through an viewer that is XDS consumer compliant.

IHE Standard--Cross Enterprise document sharing for Imaging—XDS-I--- Sharing imaging documents between radiology departments, private physicians, clinics, long term care, acute care with different clinical IT systems & thus make it possible for radiology images to become part of the patient’s EPR.

4. RIS must be a report creator & manager actors for Displayable Report Profile (with option of report repository) 

Displayable Reports (DRPT) Profile of IHE: manages creation and distribution of “display ready” (PDF or CDA) clinical reports from the creating application, to the department, and to the enterprise.

http://www.ihe-europe.net/external/framework.htm

This link identifies number of vendors participating in worldwide connectathons to show interoperability.