PID and PV1 segments of HL7 should ONLY be updated by HL7 ADT triggers from PAS.
HL7 ORM (Request) and ORU(Report) contain the following 3 segments which are important--ORC, OBR and OBX (They are used by Ordercomms, RIS, PACS, DMWL Provider (for us DMWL is provided by Rogan RIS), Teleradiology System, GP system, EPR etc). Hence, we need a consensus view on the segments, fields and their interpretation.
ORC segments has the following fields that are of importance to RIS, PACS and modalities (via the DMWL server) a. Triggers for updating the HL7 ORM message (Field 1-Order control) New Order-NW Edit Order-XO Cancel Order-CA Hold Order-RE Status Changed-SC Accession number assigned by RIS-NA (update Ordercomms) b. Order no-- Unique number generated in the Ordercomms (Field 2— Placer Order no) c. Accession no --Unique number generated in the RIS (Field 3-Filler Order no.) d. Order status (Field 5—status -requested, held, scheduled, arrived, completed, cancelled) e. Date and time of Request (Field 9—Date/Time of transaction) f. Requester –Junior doctor, nurse specialist etc may be the referrers must include name and job-role as per NHS data dictionary (Field 10-Entered by) g. Referring Consultant/GP -GMC no and Main specialty as per NHS Data Dictionary (Field 11—Verified by) h. Specialty which will do the investigation--NHS data dictionary for Main specialty codes--Radiology (Field 12 –Ordering Provider) i. Referring Location (Field 13—Enterer’s location--GP, OPD, A&E or Ward name) j. GP/Consultants Phone/extn number (Field 14—Call back phone number) k. Referring Consultants/GP Institution-Use NACS Codes for GP practice or Hospital name (Field 17—Enterers institution) l. Reason for cancellation—free text field should include the name and job role of the person cancelling the exam, and also reason for cancellation (Field 16—Order control code reason--maximum length of charcaters is 200) m. PC Identification –(Field 18—Entering Device)
OBR Segment –Called Observation Request Segment a. Order number—(Field 2—Placer Order no) b. Accession no---(Field 3—Filler Order no) c. National Exam Code and description for NHS (Field 4—Universal Service ID) d. Priority- (Field 5 –Priority) e. Requested Date/Time (Field 6) f. Radiographers completion date/time (Field 8— Observation End Date/Time) g. Results Date/Time (Field 22) h. Modality (Field 24-Diagnostic serv set ID) i. Result status (field 25—Dictated, Provisional, Verified, Addendum) j. Primary reporter name -job-role-- as per NHS data dictionary- (field 32--Principle result interpreter) k. 2nd reporter-name and job role --as per NHS data dictionary (field 33--Assistant Results Interpreter l. Radiographer/Operator(field 34—Technician) m. Transcriptionist (field 35—Transcriptionist) n. Scheduled Date/Time (field 36—appointment date and time—same as arrival date and time for walk-in patients)
OBX Segment—called observation segment. These can be multiple and repeatable. OBX is used for narrative text and can be part of both ORM and ORU messages. A. Radiology Request information will form the narrative text as OBX segment of ORM message B. Radiology Report from RIS to downstream systems –OBX of ORU OBX Fields--- Type of data –TX -text (field 2-Value type) Narrative Report (field 5—Observation value) Status of report—(Field 11-- Observation Result status)
Requester, Reporter and Operator should have the followiing information in the Ordercomms and RIS Database a. Full Name b. National ID--GMC no--when available c. Job Role--as per NHS data dictionary d. Main specailty--as per NHS Data Dictionary e. Institution--NACS Code
For example Neelam Dugar,12345,Consultant,Radiology,Doncaster and Bassetlaw Hospitals
This principle would apply to ORC segment--Field 10 (Entered by) Requester –Junior doctor, nurse specialist etc may be the referrers ORC segment--field 11 (Verified by)---Referring Consultant/GP OBR segment field 32--Principle result interpreter) ---Primary reporter OBR segment field 33--Assistant Results Interpreter --2nd reporter OBR segment (field 34—Technician--Operator usually the radiographer
posted on Monday, November 16, 2015 - 11:16 am
When we implemented Order Comms back in 2009 we stopped printing radiology reports for electronically generated requests. Whilst the process for viewing and acknowledging results is pretty well embedded now there are still pockets of referrers who have some way to go so have a number of failsafe processes remaining. As this is the desired process for managing Radiology results we are now being asked to "report" all radiology events so that referring clinicians can use the same process to manage and acknowledge rejections, cancellations,DNA etc.Status updates are currently provided back to Order Comms from RIS and we have failsafe processes to ensure that the referrer gets a "trigger" for these events but we are being told this is not enough. I was wondering if anyone else had been asked to "report" these events (status changes) and what the groups thoughts on this requirement are?
We have been 'live' with internal Order Comms requesting for nearly 2 years. We worked hard with the Order Comms supplier to create a workflow especially for rejected and cancelled events that we thought was really useful - that is when events are rejected or cancelled on RIS the request changes colour (on the order comms system) to highlight this change to the clinician. Unfortunately, we couldn't leave it at this so the radiology secretaries have to run stats every day for rejected / cancelled events and email the referrer to inform them.
Looking back at when we had paper requests, if the request was not acceptable it was sent back to the clinician and like so many processes, this piece of paper was the trigger for 'something' to happen.
Personally I think it seems a real shame to have to resort to emailing referrers when there is a system which displays this information, but clearly the current solutions are not encompassing all requirements....or maybe they are and its a change management problem - I'm not sure!
posted on Monday, November 16, 2015 - 02:29 pm
Thanks Heidi, Your situation sounds similar to ours but apparently running the stats and emailing them out is not sufficient? All of the information required is already in ordercomms but referrers only want to "manage" results. Hence the request to "report" all events. Radiology do not feel that is appropriate both from a clinical and activity reporting perspective and from the research I have done I think we are meeting RCR and IHE guidelines / standards.
Each request should "end" in either a report OR cancellation.
ELECTRONIC COMMUNICATION There should be either a report document/message or a cancellation letter/message. 1. Report is transmitted via HL7 ORU message with narrative content in OBX:5 2. Cancellation Reason is transmitted in HL7 ORM in ORC:16 Both messages are sent to ALL systems by RIS 1. Ordercomms 2. PACS 3. Can be sent to EPR, GP systems etc via standard HL7 messaging too
PAPER COMMUNICATION: We also printed report sent to referrer OR a printed Cancellation letter.
We allow free text reason for cancellation along with codes as well. The free text very useful when trying to explain why the exam was cancelled.
Reason for Cancellation is as much a part of imaging history--as the report and image is.
All reasons for cancellation are displayed on PACS and also Ordercomms, clinicians have never asked for telephone notification etc.
We also store reason for cancellation in the VNA both as a XDS document as well as a DICOM database event (without images).
There are 3 separate issues being discussed here 1. Communication of reports and cancellation reasons a. electronic--HL7 ORU for reports and ORM ORC:16 for cancellation sent to PACS, Ordercomms, EPR etc b. Paper --reports and Cancellations letters 2. Communication of Failsafe Alerts--via OBX:8 to PACS, Ordercomms, EPR etc 3. Push Notification of Failsafe Alerts a. EPRs can be configured to send push notification of failsafe alerts (when EPR receive an abnormal flag in OBX:8) via email, text message alert to bleep/smartphone etc b. Manual process of push notification--telephone call, fax etc
My view is that radiology departments responsibilty ends when we 1. Communicate the report/cancellation via standard HL7 messaging to enterprise system (print to paper as per Trust policy) 2. Communicate failsafe alert via electronic process and/or manual process (as per Trust policy). NB; Configuring EPR systems to forward alerts to referrers emails/smartphone should be the referrers responsibility. Reading and acting upon results is also a referrers responsibility
posted on Tuesday, November 17, 2015 - 09:26 am
Thank you Neelam so you would agree that the request to send (if possible) electronic ORU messages for cancellation is inappropriate?
posted on Tuesday, November 17, 2015 - 10:03 pm
I think it is entirely appropriate that we communicate both "radiology reports" and "reason for cancellation" to the referring clinicians--in a consistent way.
Regarding HL7 standards: 1. "Radiology Reports" are transmitted as an HL7 ORU message 2. "Reason for Cancellation" is transmitted as an HL7 ORM message.
Make sure that your RIS, PACS, EPR, Ordercomms suppliers all support HL7 standards appropriately.
posted on Wednesday, November 18, 2015 - 09:04 am
Thank you. Our suppliers do support HL7 as required.