purpose · web viewif the ‘sites’ attribute isn’t configured, i.e. is null, no further site...

RIS_PD154

© Healthcare Software Solutions 2017 All Rights Reserved Commercial in ConfidenceEffective Date – SJV 20/12/2017HSS Doc ref: document.docx of 48

Contents:1. Introduction....................................................................................................4

1.1 Purpose..........................................................................................................................................4

1.2 Audience........................................................................................................................................4

2. Implementation Model...................................................................................52.1 Overview........................................................................................................................................5

2.2 Application Data Flow.....................................................................................................................5

2.3 HL7 version....................................................................................................................................5

3. Dual Order Communications........................................................................64. Message & Activity Mapping – OCS to CRIS..............................................7

4.1 Creation of a new order..................................................................................................................7

4.2 Cancel an existing Order................................................................................................................7

5. Message and Activity mapping – CRIS to OCS..........................................85.1 Create an appointment for an order...............................................................................................8

5.2 Patient Attends...............................................................................................................................8

5.3 Order Cancelled.............................................................................................................................8

5.4 Order Changed...............................................................................................................................8

5.5 Additional examination added........................................................................................................8

5.6 Examination performed..................................................................................................................9

5.7 Report entered...............................................................................................................................9

5.8 Report verified................................................................................................................................9

5.9 Report amended.............................................................................................................................9

5.10 Report acknowledged.................................................................................................................9

5.11 Unsolicited Results....................................................................................................................10

5.12 Status changes.........................................................................................................................10

6. Message Transport......................................................................................116.1 Connections.................................................................................................................................11

6.2 Transport level Acknowledgements.............................................................................................11

6.3 Framing Characters......................................................................................................................11

7. Error handling..............................................................................................128. Data Mappings – OCS to CRIS...................................................................13

8.1 Patient Identifiers..........................................................................................................................13

8.2 Null values....................................................................................................................................13

8.3 Segment mappings......................................................................................................................14


8.3.1 MSH.........................................................................................................148.3.2 MSA.........................................................................................................158.3.3 PID...........................................................................................................168.3.4 PV1...........................................................................................................178.3.5 PD1..........................................................................................................188.3.6 ORC.........................................................................................................198.3.7 OBR.........................................................................................................208.3.8 OBX..........................................................................................................218.3.8.1 Images..................................................................................................228.3.9 NTE..........................................................................................................238.3.10 DG1..........................................................................................................249. Sample Message and mapping to CRIS user interface............................2510. Data Mappings – CRIS to OCS.................................................................31

10.1 Time Stamp values...................................................................................................................31

10.2 Messages..................................................................................................................................31

10.2.1 OMG^O19 Order Message.....................................................................3110.2.2 ORG^O20 Order acknowledgement.....................................................3110.2.3 ORU^R01 Clinical Report......................................................................3211. Order control and status summary.........................................................3312. CRIS to HL7 Segment mappings.............................................................34

12.1 MSH..........................................................................................................................................34

12.2 MSA..........................................................................................................................................35

12.3 PID............................................................................................................................................36

12.4 PV1...........................................................................................................................................38

12.5 ORC..........................................................................................................................................39

12.6 OBR..........................................................................................................................................41

12.7 OBX...........................................................................................................................................43

13. CONFIGURABLE ITEMS REQUIRED BY THE INTERFACE...................44


1. Introduction

1.1 PurposeThis document intends to define the transport protocols, message mappings and definitions for integration of CRIS with a local Order Communications System (OCS)

This version of the specification applies to CRIS interface release 2.10.00.

1.2 AudienceThis document is intended for system integrators, third party suppliers and potential customers. The reader is assumed to be familiar with the HL7 standard.


2. Implementation Model2.1 OverviewCRIS receives requests for examinations as order request messages from OCS. Radiology staff are notified of outstanding orders via the CRIS user interface. As orders are fulfilled and reported status messages are returned to OCS.

2.2 Application Data FlowCRIS receives Orders as HL7 messages over TCP/IP using the HL7 Minimal Lower Layer Protocol. Orders are stored in the CRIS database and acknowledgements are returned to OCS.

Each order is treated as a single entity; however the Radiology department may decide to perform several orders as a single attendance.

OCS may send multiple orders per HL7 message by repeating ORC & OBR segments if desired by utilizing a blank BLG segment (highlighted) as can be seen in the example below. CRIS will always send a single order per message.

MSH|^~\&|||||||OMGÔ19|||2.4PID|||Z000007^^^HSS^MR||TEST PATIENT^MALE^^^MR||20051010|M|||HSS HOSPITAL^HSS ROAD^SOME CITY^SOME COUNTY^X99 9XX||0123456789|||||||||APD1|||^^M85773|G3430460PV1|||||||||C9999998|||||||||A|0000000ORC|NW|124349|||||||20090323092146027|^PandyÂndy||C9999998|||||300||||^^HSS01OBR||||XELBR|||||||||||||||||||||||^^^20090323000000000^^1|||WNTE|1||HelloNTE|2||(Request made by: Andy Pandy, Tel/Bleep: XXXX)OBX|1|TX|CATEGORY||N||||||OBX|2|TX|REQUESTING LOCATION||TEST||||||OBX|3|TX|ALERTS \T\ ALLERGIES||(Allergy: Cheese)||||||OBX|4|TX|SPECIAL NEEDS||(Sight)||||||BLG|ORC|NW|124350|||||||20090323092146027|^PandyÂndy||C9999998|||||300||||^^HSS01OBR||||XELBL|||||||||||||||||||||||^^^20090323000000000^^1|||WNTE|1||HelloNTE|2||(Request made by: Andy Pandy, Tel/Bleep: XXXX)OBX|1|TX|CATEGORY||N||||||OBX|2|TX|REQUESTING LOCATION||TEST||||||OBX|3|TX|ALERTS \T\ ALLERGIES||(Allergy: Cheese)||||||OBX|4|TX|SPECIAL NEEDS||(Sight)||||||

Status updates, clinical reports and orders made on CRIS are communicated to OCS also as HL7 messages over TCP/IP. OCS returns application level acknowledgements to CRIS

Many sites may wish to make use of an integration engine, in which case as far as CRIS is concerned the integration engine is the OCS.

2.3 HL7 versionAll messages referenced in this document conform to the 2.4 version of the HL7 standard. Message transport is HL7 MLLP over TCP/IP.


3. Dual Order Communications

To facilitate the requirements within Trusts for dual OCS functionality two new interface attributes have been included. These will allow further control over the flow back of messages out of CRIS.

‘OriginatingOCS’ – if required, must be used on BOTH the incoming and outgoing OCS interfaces. If not configured, no specific OCS validation will be made, thus message will be sent to all OCS feeds.

‘FilterUnsolicitedReports’ – When used should be used and set either ‘true’ or ‘false’. If set to ‘true’ and OCS validation is made, the report will only be sent back to the originating OCS. If set to ‘false’, no specific OCS validation is made and reports will be sent to all connected OCSs. This will only occur when a report is verified unless the ‘SendUnverifiedReports’ exists and set to ‘true’.

In conjunction with the two attributes above, the ‘Sites’ attribute, configured in the outgoing OCS interface only, is used for further validation of a ‘change’ message.

Validating the ‘Sites’ attributeIf the ‘Sites’ attribute isn’t configured, i.e. is null, no further site validation is required and the message is allowed to carry on. If the attribute has a value(s), this value is validated against data in the message. If the values match, the message is allowed to carry on, however, if no match is found, it is deemed to be invalid and the message will not be sent, irrespective of the condition of the ‘OriginatingOCS’ attribute.

Validating the ‘OriginatingOCS’ attributeIf the ‘OriginatingOCS’ attribute isn’t configured, i.e. is null, no further OCS validation is required and the message is allowed to carry on. If the attribute has a value, this value is validated against data in the message. If the values match, the message is allowed to carry on, however, if no match is found, it is deemed to be invalid and the message will not be sent, irrespective of the condition of the ‘Sites’ attribute.

Validating the ‘FilterUnsolicitedReports’ attributeAgain, the ‘Sites’ attribute is validated as described above. If all is well, we now check to see what the interfaces want to do with unsolicited reports.If the ‘FilterUnsolicitedReports’ isn’t configured or set to ‘false’, no specific OCS validation is carried out and the report message is sent to all connected OCSs.If the ‘FilterUnsolicitedReports’ is set to ‘true’, the ‘OriginatingOCS’ attribute is validated as described above. If all is well, the report will only be sent to the originating OCS, any other connected OCS will fail the validation and the report will not be sent.


4. Message & Activity Mapping – OCS to CRIS

4.1 Creation of a new orderWhen a new order is entered on OCS it should send an OMGÔ19 message with order control “NW”. CRIS will acknowledge receipt of this with an ORGÔ20 message indicating success or failure to store the order. Note that the PID segment of the ORGÔ20 message is a copy of the PID segment found in the OMGÔ19 sent by OCS.

4.2 Cancel an existing OrderWhen a clinician cancels a previously requested order OCS should send an OMGÔ19 with order control “CA”. Orders may only be cancelled prior to them being accepted on CRIS. CRIS will return an ORGÔ20 indicating success or failure of the cancellation (“OC” – order cancelled or “UC” – unable to cancel). Note that the PID segment of the ORGÔ20 message is a copy of the PID segment found in the OMGÔ19 sent by OCS.

As part of 2.09.10t1g release the circumstances around the OCS being allowed to cancel an order held by CRIS has been extended. If OCSCancellingCRISEvent is requested to be set to TRUE (default is FALSE) then an order can be cancelled at any point up to it becoming an attendance or an appointment by the OCS.


5. Message and Activity mapping – CRIS to OCS

5.1 Create an appointment for an orderWhen a user on CRIS has made an appointment for an order CRIS will send an OMGÔ19 message with order control set to “SC” (status change) and a status value of “SC” (scheduled)

5.2 Patient AttendsWhen a patient attends for their examination, they will be booked in to the CRIS reception module. At this point CRIS will send an OMGÔ19 message. For attendances that had an appointment booked order control will be set to “SC” (status changed), otherwise we will send the following order control values;

"NW", Order status of "IP" when patient is directly attended in to CRIS"NW", Order status of "SC" when patient is directly appointed (appointment made)"XO", Order status of "SC" when the attended direct from a request"SC", Order status of "IP" when attended from a waiting list

5.3 Order CancelledA user on CRIS may decide to cancel an order, at which point CRIS will send and OMGÔ19 message with order control set to “CAW” and a status of “CA”

OCS should respond with an ORGÔ20 with order control either set to “OC” (order cancelled) or “UC” (unable to cancel), however regardless of this the examination will not be performed.

5.4 Order ChangedThe Radiology department may decide that the examination requested on an order is inappropriate and replace it with another. At this point CRIS will send an OMGÔ19 message with order control set to “XO” with the revised details.

OCS should respond with an ORGÔ20 with order control either set to “XR” (changed as requested) or “UX” (unable to change). If the result is “UX” subsequent status and result information will not be sent for this order.

5.5 Additional examination addedThe Radiology department may decide that additional examinations are appropriate to the fulfilment of an order. In this case CRIS will send an OMGÔ19 message (order control=”NW”) for each new examination. The <visit number> field (PV1:19) will be populated with the value received on the first order in the attendance.

OCS should respond with an ORGÔ20 with order control either set to “OK” (order accepted) or “UA” (unable to accept order)

5.6 Examination performedWhen the procedure has been performed the radiographer enters the screening and projection data on CRIS. At this point CRIS will send and OMGÔ19 message with order control set to “SC” and a status of “CM” (complete).© Healthcare Software Solutions 2017 All Rights Reserved Commercial in ConfidenceEffective Date – SJV 20/12/2017HSS Doc ref: document.docx of 48

5.7 Report enteredWhen the clinical report is entered on CRIS an ORU^R01 message containing the preliminary report is sent with a result status of “P” (preliminary).

5.8 Report verifiedOnce the Radiologist is satisfied with the clinical report it will be verified. At this point CRIS will send an ORU^R01 containing the report with a result status of “F” (final)

5.9 Report amendedIf for some reason the radiologist later needs to change a previously verified report an addendum will be added, and the report then re verified. CRIS will then send an ORU_R01 containing the report with a result status of “C” (changed)

5.10 Report acknowledgedCRIS is able to accept notifications from an OCS when a report has been accepted/viewed. This is recorded at an event level so the first exam in a group of exams against an event would flag for all. The subsequent details for the other exams would be appended to the details already received.

A cut down version of the message showing the fields (highlighted) that we expect for this functionality to work within CRIS is given below.

MSH|^~\&|CRIS|LIVE|||20171218093103||OMG^O19|JAXZJ6WP:2|P|2.4|PID|||<HospNo>^^^<AssigningAuth>^MRORC|SC||||RAOBR|||<CRIS ExamKey>NTE|1||<YYYY.MM.DD>, <hh.mm.ss>, <User who acknowledged>, <Free text description>

A more typical (example) message that we would expect from OCS is given below.

MSH|^~\&|OCS|LIVE|CRIS|LIVE|20171218095003||OMG^O19|K0C7M7AT:1PU|P|2.4||||||| PID|||399^^^CRIS^PI~307HSS^^^HSS01^MR||TEST^STE^^^MR||19811204|M|||7 PRIORY ROAD^MANSFIELD WOODHOUSE^MANSFIELD^NOTTINGHAMSHIRE^NG19 9LP||||||||||||||||||""|N PV1||O||||||||||||||||C ORC|SC|OCS00146/001|101260^CRIS||RA||^^^201712180000^^5||201712051214|STEVEV||C999^CLOONEY G|HSS01AED||201712050000|^|180|DEVLAPTOP|STEVEV||^^HSS01 OBR|||101260^CRIS|XPELV^XR Pelvis||||||||||||||||9673431|HSS00101260|||M|||^^^201712180000^^5|||||||^20171218^20171218^^^^HSS01NTE|1||2017.12.18, 09.50.00, OrderComms, Acknowledgement of resultNTE|2||2NTE|3||3


5.11 Unsolicited ResultsClinical reports for attendances that have not been ordered will be transmitted as unsolicited results for any patient who has a hospital number associated with a particular OCS unless the Trust considers the use of SITE filtering.

5.12 Status changesCRIS supports arbitrary user defined examination statuses. It is possible to configure the interface to generate an outbound HL7 status message for these by adding a status code map.


6. Message Transport

All Messages are transmitted over TCP/IP using MLLP.

6.1 ConnectionsOne socket connection is used for messages originating from each system. The port numbers to be used will be decided by mutual agreement. CRIS will initiate the connection (act as client) for messages going from CRIS to OCS. PAS will initiate the connection for messages going from OCS to CRIS.

6.2 Transport level AcknowledgementsEach message will be acknowledged by the receiving system prior to delivery of the next message. Messages that are NAK’d should be logged.

6.3 Framing CharactersStandard HL7 MLLP framing characters will be used, these are

<0B> start of message<1C> end of message

In addition MLLP requires that each message be followed by carriage return <0D>


7. Error handling

CRIS logs errors that are encountered when generating and processing messages as well as any error messages in the MSA segments received in response to outbound messages. It is expected that the OCS system will also maintain its own logs.


8. Data Mappings – OCS to CRIS

8.1 Patient IdentifiersAll patient identifiers should be passed in PID:3. Components 1, 4 & 5 are required by CRIS, component 2 can be optionally sent to the OCS if requested, and all other components are ignored. One of the passed identifiers should be the primary key used on PAS & OCS, the Assigning authority/Identifier Type Code for this identifier will be pre-determined during system configuration.

Sequence Name Usage1 ID Number Patient Identifier2 Check Digit Optional, only used for NHS number if requested by the

Trust. Standard codes are in CRISNHSV table, namely, 01 = Number present and verified, 02 = Present but not traced, 03 = Trace required, 04 = Trace attempted, no or multiple matches found, 05 = Trace needs to be resolved (NHS number or patient detail conflict), 06 = Trace in progress, 07 = Number not present and trace not required, 08 = Trace postponed (baby under 6 weeks old)

4 Assigning Authority “NHS” for NHS number“CHI” for CHI (Community Health Index) numberOtherwise the code identifying a hospital for hospital numbers.

5 Identifier Type Code “NH” for NHS number/ CHI number“MR” for hospital numbers

8.2 Null values

If a field is not supported it should not be sent, where a blank or null value is held it should be sent as “”.


8.3 Segment mappings

Mappings of HL7 data items to the CRIS data model. Items not mentioned here are ignored by CRIS.

8.3.1 MSH

This segment should appear on all messages.

Position Name Max Width

Usage

1 Segment Delimiter 1 CRIS only supports the HL7 default segment delimiter |

2 Encoding characters

4 CRIS only supports the HL7 default encoding characters ^~\&

3 Sending Application 24 Stored if present along with DG1 segment data

4 Sending Facility 12 Stored if present along with DG1 segment data.

9 Message Type Both message type and trigger type are mandatory.9.1 Message Type 39.2 Trigger Event 310 Message Control ID 20 Used to uniquely identify the message, this value will be returned

in MSA:2 of any acknowledgements.

12 Version ID 3 CRIS supports the 2.4 version of the HL7 specification


8.3.2 MSA

This segment should appear on ORG^O20 messages

Position Name Max Width Usage2 Message Control ID 10 The ID of the order message being

responded to


8.3.3 PID

The PID segment appears on all messages defined in this document. PID:3 is the only field used by CRIS, however other fields may be filled in accordance with PD 151 to improve message readability for administrators. CRIS will not register a patient in response to any order message.


Usage

3 Patient ID (Internal)

Refer to the notes on patient identifiers above.

3.1 ID 153.2 Check Digit 2 Optional3.4 Assigning

Authority5

3.5 Identifier type code

2


8.3.4 PV1

For CRIS the PV1 segment is only relevant for new order messages. For other messages it is ignored.


Usage

3 Assigned Patient Location

15 Current patient location / ward

9 Consulting Doctor 8 The consultant in charge of the patient. This will be mapped to the lead clinician on CRIS. Only <ID Number> is used.

10 Hospital Service 64 Episode description

17 Admitting Doctor 24 Admitting Doctor / Physician

18 Patient Type 1 Patient type, e.g. Inpatient or Outpatient etc, This field, if present, will override the default patient type which is normally determined by the ward code. If used this field may need to be mapped to match the lookup table on CRIS.

19 Visit Number 30 Episode identifier from OCS. New orders booked on CRIS as being additional to this order will be sent with the same value.


8.3.5 PD1

PD1 is not referenced as part of an Order message.


Usage

3.3 Patient Primary facility

9 Patients registered GP practice.<id number> should contain the national GP practice code.Note that <id number> is the third sub component.

4 Patient Primary care provider and name

10 <id number> should contain the national code for the patients registered GP


8.3.6 ORC

The ORC segment should appear on OMGÔ19 and ORGÔ20 messages.


Usage

1 Order Control 2 Identifies the type of order message. Possible values are“NW” New Order (OMGÔ19)“CA” Cancel Order (OMGÔ19)“OC” Order Cancelled (ORGÔ20)“UC” Unable to Cancel (ORGÔ20)“XR” Order Changed (ORGÔ20)“UX” Unable to Change (ORGÔ20)

2 Placer Order Number

30 Unique order ID allocated by OCS, only <Entity Identifier> is used.

3 Filler Order Number 10 Unique order ID allocated by CRIS. When generating Acknowledgement messages OCS should fill this with the value found in the message that is being acknowledged. Only <Entity Identifier> is used.

4 Placer Group Number

22 Optional, if required you need to request that GENERAL.CheckGroupWhenCombiningOrders is set to TRUE (default is FALSE). If set to TRUE then the text from the clinical history, event comment, reason for exam and safety questions are taken from the first order.

9 Date/TimeOf Transaction

26 The date and time that the order was placed.

10 Entered By The person who entered the order.10.2 Family Name 32 <family name> is appended to <given name> and <middle initial>

components. Any characters passed the max width will be truncated

10.3 Given Name

12 Ordering Provider 15 The clinician responsible for entering the request, this field maps to the referrer field on CRIS. Only <id number> is used.

13 Enterers Location 15 This maps to the ward field on CRIS. Only <point of care> is used.

16 Order ControlCode Reason

50 For acknowledgements and cancellations CRIS will log the value of the <text> component

17 Entering Organization

8 <identifier> should contain the specialty of the ordering clinician.

19 Action By Should identify the person who initiated the event that triggered this message, In this case of a NW order this would be the same person identified in ORC:10, in the case of a CA it would be the person who cancelled the order. CRIS does not currently make use of this field

21 Ordering facility Name

9 <id number> should contain the code identifying the hospital / GP practice etc. that the request was made from. In the case of a ward request CRIS can default this value based on the ward code.


8.3.7 OBR

The OBR segment should appear on OMG^O19 new order messages. For other messages it is ignored.


Usage

4 Universal Service ID 8 The examination being requested. Only <identifier> is used.

18 Placer Field 1 40 This value will be returned on subsequent response messages from CRIS for this order.

19 Placer Field 2 40 This value will be returned on subsequent response messages from CRIS for this order.

27 Quantity/Timing 26 <start date/time> should contain the date and time the examination is required. <priority> should contain the priority of the order, this component may need translation.

30 Transportation Mode 1 Transportation mode for this patient.This field may require translation, refer the CRIS installation on site for actual values.


8.3.8 OBX

OBX segments should appear on OMG^O19 new order messages. For other messages they are ignored.

Multiple OBX segments may be sent to provide information relevant to the request that is not otherwise available in the ORC and OBR segments. Certain types of information have specific fields within the CRIS database, such as LMP and Pregnancy. The Observation Identifier should be populated to identify the type of information being provided. CRIS can then be configured to either include a specific piece of information in the clinical notes or place it in a more specific field.

Position Name Max Width2 Value Type 2 – Must be TX3 Observation Identifier 305 Observation Value Dependent on observation value – see below

The following observation identifiers are recognized by CRISID Max

WidthDescription

LMP 8 Date of patients last menstrual period, this should be in the format YYYYMMDD

PREGNANT 1 Whether or not the patient may be pregnant, values should be Y,N or blank

CATEGORY 1 Request category, If this is not supplied CRIS will default the value based on the ward code

SITE 5 Site the order is to be performed at, If this is not supplied CRIS will default the value based on the ward code.

PATHWAY 32 The Pathway ID associated with this order.

CONTACT NUMBER

25 The contact number for the order

REASON 2048 The reason for the examination. CRIS is only expecting one REASON OBX per message. If more than one is received only the LAST one will be stored

QUESTIONS Clinical Information – added to the clinical safety questionsRENAL FUNCTION

Clinical Information – added to the clinical safety questions

CREATININE LEVEL


CREATININE DATE


RESULTS Clinical Information – added to the clinical safety questions


8.3.8.1 Images

As a chargeable option, images and other documents may be sent to CRIS by including them as OBX segments with a value type of ED. The image is stored within the standard CRIS AVData format used for request cards.

The elements of the OBX segment are treated as follows

Observation Identifier <Identifier> should contain the data type – eg REQCARD for request card

Observation Value <Data Sub Type> should the encoding of the document being delivered – eg JPEG<Data> Should contain the data for the document encoded as Base 64


8.3.9 NTE

NTE segments may be present in order to send clinical history text.


Notes

1 Set ID 4 Sequence, first NTE in a message should be 1, followed by 2 etc.

3 Comment 2k Each comment section should contain 1 line of the clinical history.The max width of 2k refers to the total size of the clinical history.


8.3.10 DG1DG1 segments may be present in order to send diagnosis information.

Note: Please contact HSS to discuss using this segment


Notes

3.1 Diagnosis code 30 Diagnosis code3.2 Description 64 Description3.3 Coding system 30 Coding system5 Diagnosis

date/timeDiagnosis date/time

6 Diagnosis type 1 Diagnosis type15 Diagnosis priority 1 Diagnosis priority16.1 Diagnosing

clinician24 Diagnosing clinician

17 Diagnosing classification

1 Diagnosis classification

18 Confidential 1 Confidential indicator (Y or N, any other value will be stored as blank)

19 Attestation Attestation date


9. Sample Message and mapping to CRIS user interfaceThe following screen shot provides an overview of the fields within an OMG^O19 message that we process and their place within the main event details screen.

Subsequent screen shots cover the remaining screens that an order can populate.


MSH|^~\&|OCS|LIVE|||||OMG^O19|1234567890||2.4PID|1||45502HSS^^^HSS^MRPV1|||HSS01AED||||||C911|EPISODE DESCRIPTION|||||||G8042754|G|EPI12345PD1|||^^C84087|G8042754ORC|NW|HSS000000035||GRP12345|SC||||201607271200|RA00222^SMITH^HELEN||C911|HSS01AED||||100||RA00222||^^HSS01OBR||||CFOOR||||||||||||||MISCELANEOUS1|MISCELANEOUS2||||||||^^^201607271200^^1|||WNTE|1||CLINICAL INFO LINE 1NTE|2||ADDITIONAL INFO ON LINE 2NTE|3||LINE 3NTE|4||LINE 4NTE|5||LINE 5DG1|||TEST^TEST DIAGNOSIS CODE^TEST||201607271200|A|||||||||1|C999|D|N|201607271000OBX|1|TX|IV||NOOBX|2|TX|O2||YESOBX|3|TX|CATEGORY||NOBX|4|TX|REASON||Reason for exam line 1OBX|5|TX|QUESTIONS||Question 1

Site is either taken from an OBX:5 defined value where OBX:3 = “SITE” or if not present it is derived from the ward code provided in ORC:13


MSH|^~\&|OCS|LIVE|||||OMG^O19|1234567890||2.4PID|1||45502HSS^^^HSS^MRPV1|||HSS01AED||||||C911|EPISODE DESCRIPTION|||||||G8042754|G|EPI12345PD1|||^^C84087|G8042754ORC|NW|HSS000000035||GRP12345|SC||||201607271200|RA00222^SMITH^HELEN||C911|HSS01AED||||100||RA00222||^^HSS01OBR||||CFOOR||||||||||||||MISCELANEOUS1|MISCELANEOUS2||||||||^^^201607271200^^1|||WNTE|1||CLINICAL INFO LINE 1NTE|2||ADDITIONAL INFO ON LINE 2NTE|3||LINE 3NTE|4||LINE 4NTE|5||LINE 5DG1|||TEST^TEST DIAGNOSIS CODE^TEST||201607271200|A|||||||||1|C999|D|N|201607271000OBX|1|TX|IV||NOOBX|2|TX|O2||YESOBX|3|TX|CATEGORY||NOBX|4|TX|REASON||Reason for exam line 1OBX|5|TX|QUESTIONS||Question 1


10. Data Mappings – CRIS to OCS

910

10.1 Time Stamp values

CRIS will always populate time stamps with as much data as is available, in some cases this will include year, month, day , hours, minutes, seconds, milliseconds and time zone offset, in other cases hours, minutes seconds milliseconds and time zone may not be available. The PAS should follow the standard HL7 guidelines for processing of time stamps.

10.2 Messages CRIS sends three messages, OMGÔ19, ORGÔ20 and ORU^R01.

10.110.2

10.2.1 OMGÔ19 Order Message

The order message is used to pass status information, new orders booked on CRIS and order cancellations. The meaning of an order message is specified in ORC:1 - Order Control.

Code Message TypeNW New order booked on CRISCA Cancellation of an existing orderXO Change order requestSC Status Changed

10.2.2 ORGÔ20 Order acknowledgement

The order acknowledgement message is sent in response to received new orders and order cancellation messages. ORC:1 defines the type of acknowledgement

Code Message Type

OC Order cancelledUC Unable to cancel

OK Order Accepted OKUA Unable to accept order


10.2.3 ORU^R01 Clinical Report

The ORU^R01 message is used to transmit clinical reports to OCS. ORC:1 will always contain “SC” for status change with a status value , ORC:5, of “CM” for complete.

On CRIS clinical reports may be entered at the attendance and/or the examination level. On printed output the attendance summary and reports for each individual examination are appended to produce the complete reports.

Result messages sent for orders are generated in the same manner, so orders that where performed together will each be sent a copy of the full report.

For Example: Two examinations are ordered, a Left Foot and a Right Arm. The Radiology department decides to perform the two examinations on a single attendance and the following three reports are entered.

SummaryThis person can neither walk nor write.

Left FootLeft foot appears to be missing

Right ArmThe right arm is mostly complete; however the patient is missing four fingers and a thumb.

CRIS will send the following identical report for both the left foot and right arm orders

This person can neither walk nor writeLeft footLeft foot appears to be missing

Right armThe right arm is mostly complete; however the patient is missing four fingers and a thumb.


11. Order control and status summary

The following table lists the order control and status value combinations that will be produced by CRIS.

Message Type Order Control

Status Meaning

OMG^O19 NW SC New order booked on CRIS, appointment bookedIP New order booked on CRIS, patient in dept.

SC SC Status change, appointment bookedIP Status change, patient in dept.CM Status change, examination performed

CA CA Order cancelledXO SC Order changed, appointment booked

IP Order changed, patient in dept.ORG^O20 OK n/a Acknowledgement for new order, ok

UA n/a Acknowledgement for new order, order not acceptedOC n/a Acknowledgement for cancellation, cancelled.UC n/a Acknowledgement for cancellation, order not cancelled.

ORU^R01 SC CM Clinical report


12. CRIS to HL7 Segment mappings

1112

12.1 MSH

MSH appears on all messages


Notes

1 Field Separator 1 Always Populated with “|”2 Encoding Characters 4 Always Populated with “^~\&”

3 Sending Application 180 Defaults to “CRIS” may be configured to send any fixed value.

4 Sending Facility 180 Defaults to “LIVE” may be configured to send any fixed value.

5 Receiving Application 180 Default is empty, may be configured to send any fixed value.

6 Receiving Facility 180 Default is empty, may be configured to send any fixed value.

7 Date Time of Message 26 Populated with the date and time that the message was generated, century, year, month, day, hour, minute, second, millisecond and time zone offset are all present.

9 Message Type The type of the message. CRIS sends the messagesOMG^O19ORG^O20ORU^R01

9.1 Message Type 39.2 Trigger Event 3

10 Message Control ID 20 Populated with a unique id for the message

11 Processing ID 1 Set to “P”12 Version ID 3 Set to “2.4”


12.2 MSA

This segment will appear on ORG^O20 messages


Usage

1 Acknowledgement Code

2 Will be set to Either “AA” (Application accept), “AE” (Application error) or “AR” (Application reject) depending upon the success or failure of the message being responded to.

2 Message Control ID 20 The ID of the order message being responded to


12.3 PID

PID appears on all messages. Note that the ORG^O20 message contains a PID that is a copy of the PID segment received in the OMG^O19 message.


Notes

3 Patient ID Internal Will contain a list of the patient identifiers known by CRIS, refer to the notes on patient identifiers.

3.1 ID 153.2 Check Digit 2 Optional, for NHS number use only. If required then you must

request that SendNHSVerStatus is set TRUE, NHSVerStatusInIDReliabilityCode is set FALSE, if set TRUE then we put this value in PID:32. If you only want verified NHS numbers (01) then you must request SendVerifiedNHSNumOnly is set to TRUE (default is FALSE)

3.4 Assigning Authority 53.5 Identifier Type

Code2

5 Patient Name Only the first occurrence is populated.5.1 Family Name 64 <Family Name> is populated with surname from CRIS.

5.2 Given Name 64 Forenames on CRIS is split at the first space character, the substring prior to the space is placed in <Given Name>, the substring after the space is placed in <Middle Initial Or Name>

5.3 Middle Initial

5.4 Prefix 24 patients title is placed in <prefix>7 Date Time Of Birth 26 Patients date of birth, only century, year, month and day are

populated8 Patient Sex 1 This field may require translation, values on CRIS are

F FemaleM MaleI IndeterminateU Unknown

10 Race 3 Patient’s race. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE

11 Address CRIS has four lines of address plus post code.11.1 Street Address 50 The first line is placed in <street address>11.2 Other Designation 50 The second line is placed in <other designation>

11.3 City 35 The third line is placed in <city>11.4 State 35 The Fourth line is placed in <province>11.5 Zip or postal Code 8 The two components of post code are combined and placed in <zip

or postal code>12 County Code 9 County code. Only populated if SendAdditionalPatientInfo is TRUE.

By default this is FALSE


13 Phone number home

Patients home telephone number, email address and mobile number.Mobile telephone number is placed in the next repeating instanceEg|0115874245^^^[email protected]~07785342542|

13.1 Phone Number 25 Home Telephone number13.4 Email Address 40 Email address14 Phone number

business25 Patients work telephone number

15 Primary Language 3 Patient’s primary language. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE

16 Marital Status 1 Marital status. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE

17 Religion 3 Religion. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE

18 Patient Account Number

20 Patient Account Number. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE

22 Ethnic Group 2 This field may require translation26 Citizenship 3 Citizenship. Only populated if SendAdditionalPatientInfo is TRUE.

By default this is FALSE29 Patient Death Date

and Time26 For Deceased patients this will contain the date of death, century,

year, month and day are present. Otherwise this field will contain null (“”)

30 Patient Death Indicator

1 For deceased patients this field will contain “Y” otherwise it will be “N”

32 Identity Reliability Code

2 Optional, for NHS number use only. If required then you must request that SendNHSVerStatus is set TRUE, NHSVerStatusInIDReliabilityCode is set TRUE, if set FALSE then we put this value in PID:3.2. If you only want verified NHS numbers (01) then you must request SendVerifiedNHSNumOnly is set to TRUE (default is FALSE)


12.4 PV1

The PV1 segment is only present for ORU and OMG messages.


Usage

18 Patient Type 1

19 Visit Number 30 Episode identifier from OCS. This is populated with the value taken from the first received order on the attendance. This may be used by OCS to attach the order to the correct episode.


12.5 ORC

This is present on all messages.


Notes

1 Order Control 2 Populated according to order control and status summary table above.

2 Placer Order Number 30 Contains the placer order number received in the original new order message. In unsolicited result messages this field will be blank.

3 Filler Order Number 10 Contains the CRIS allocated order id.

5 Order status 2 Populated according to order control and status summary table above.

7 Quantity/Timing 26 <start date/time> will, for orders that have status “SC”, contain the date and time that the examination is booked for, for orders with a status of “IP” and clinical results it will contain the date and time that the examination was done.

<priority> will contain the priority of the order, this component may need translation.

Optional, if you require all 2099 type dates to be removed then you must specify that BlankWaitingDate is set to TRUE (default is FALSE). This will remove the date from ORC:7, OBR:27, OBR:34.2 and OBR:34.3

9 Date Time of transaction 26 Date and time of the user action on CRIS that resulted in this message.

10 Entered By The user on CRIS that entered the order/status/result.

10.1 ID Number 10 populated with the ID of the user20.2 Family Name 40 populated with the users name12 Ordering Provider 15 <id number> is populated with the code identifying the

referrer on CRIS13 Enterers location 15 <point of care> is populated with the code identifying the

ward/location on CRIS16 Order control code

reason2 This is only populated for ORG^O20 messages of type UA and

UC.<identifier> is populated as follows.

For messages of type “UC”

NF – Unable to find orderOS – order already scheduledOI – order already in processIE – Internal error


For messages of type “UA”

OE – Order already existsUP – Unknown patientIE – Internal Error

17 Entering Organization 8 <identifier> will contain the specialty of the ordering clinician.18 Entering Device 31 The workstation on CRIS where the order/status/result was

entered.19 Action By 10 Identifies the user on CRIS that triggered the sending of this

message. ID Number contains the CRIS user id.21 Ordering facility name 9 <id number> will contain the code identifying the hospital /

GP practice etc. that the request was made from.


12.6 OBR

This is present on all messages.


Notes

2 Placer Order Number 30 Contains the placer order number received in the original new order message. In unsolicited result messages this field will be blank.This field contains the same value as ORC:2

3 Filler Order Number 10 Contains the CRIS allocated order id.This field contains the same value as ORC:3

4 Universal Service ID 8 <identifier> contains the examination procedure code from CRIS. <text> contains the examination procedure name from CRIS.

18 Placer Field 1 40 Will be populated with whatever value was received in Placer Field 1 of the original NW order message.

19 Placer Field 2 40 Will be populated with whatever value was received in Placer Field 2 of the original NW order message.

20 Filler Field 1 40 CRIS generated event key. OCS may use this field to identify which orders have been performed as a single attendance.

21 Filler Field 2 40 CRIS generated Accession Number, this field is used by PACS systems to identify the examination. OCS may find this value useful if it needs to interface to PACS in order to view images.

22 Result rpt status changeDate/time

26 Populated on report messages onlyThis will contain the date and time that the report was typed, verified or changed (depending on result status)

24 Diagnostic Serv Sect ID 1 Populated with the modality of the examination.27 Quantity/Timing 26 <start date/time> will, for orders that have status

“SC”, contain the date and time that the examination is booked for, for orders with a status of “IP” and clinical results it will contain the date and time that the examination was done.

<priority> will contain the priority of the order, this component may need translation.This field contains the same value as ORC:7


28 Result copies to 24 Details of the “Copy To” referrer in the event details32 Principal Result Populated on report messages only© Healthcare Software Solutions 2017 All Rights Reserved Commercial in ConfidenceEffective Date – SJV 20/12/2017HSS Doc ref: document.docx of 48

Interpreter32.1.1 Name.ID 10 <id number> of <name> contains the id of the first

radiologist.32.1.2 Name.FamilyName 40 <Family Name> of <name> contains the name of the

radiologist.32.2 Start Date/Time 26 <start date/time> contains the date & time the report

was created.33 Assistant Result

InterpreterPopulated on report messages only

33.1.1 Name.ID 10 <id number> of <name> contains the id of the second radiologist

33.1.2 Name.FamilyName 40 . <Family Name> of <name> contains the name of the radiologist.

34 Technician Populated on status change status “CM” messages only

34.1.1 Name.ID 10 <id number> of <name> contains the id of the radiographer that performed the procedure.

34.1.2 Name.FamilyName 40 <family name> of <name> contains the name of the radiographer that performed the procedure.

34.2 Start Date/Time 26 <start date/time> contains the date and time the procedure was performed


34.3 End Date/Time Optional, if you require all 2099 type dates to be removed then you must specify that BlankWaitingDate is set to TRUE (default is FALSE). This will remove the date from ORC:7, OBR:27, OBR:34.2 and OBR:34.3

34.5 Room 6 <room> contains a code identifying the xray room where the procedure was performed,

34.7 Facility 5 <facility> contains a code identifying the hospital at which the procedure was performed

34.10 Building 8 <Building> contains the department code.35 Transcriptionist Populated on report messages only35.1.1 Name.ID 10 <id number> of <name> contains the id of the person

that typed the report.35.1.2 Name.FamilyName 40 Contains the name of the person that typed the

report.35.2 Start Date/Time 26 <start date/time> contains the date & time the report

was typed.


12.7 OBX

OBX segments are present on clinical report messages. One OBX for each paragraph of report.


Notes

1 Set ID 1 Set to “1”2 Value Type 2 Set to “TX”3 Observation Identifier 8 <identifier> contains the examination code for the order

5 Observation Value 4k Contains one paragraph of the textual report.

8 Urgency 1 Populated if the “SendUrgentFlag” is set TRUE, default is FALSE. Produces an additional OBX line in the message containing one of ‘R’, ‘C’, ‘U’ or ‘S’, meaning Routine, Critical, Urgent or Significant finding.

An example OBX is as follows:

OBX|5|TX|URGENT^^CRIS3|||||U

11 Observation ResultStatus

1 Indicates the status of the report on CRISP Preliminary reportF Final ReportC Changed report

14 Date & Time OfThe Observation

26 This will contain the last date and time that the report was typed, verified or changed (depending on result status)

16 Responsible Observer 51 Either the last reporting radiologist or (in the case of a verified report) the radiologist that verified the report. <id number> contains the identifier of the radiologist, <family name> contains the name of the radiologist.


13. CONFIGURABLE ITEMS REQUIRED BY THE INTERFACE

OUTBOUND IP and PORT

IP that the HSS interface will connect to and the port you will be listening on.SENDING APPLICATION

What value you will be putting in to MSH:3 (if any)

SENDING FACILITY


RECEIVING APPLICATION


RECEIVING FACILITYWhat value you will be putting in to MSH:6 (if any)

NHS Number formatDo you require the NHS in its default format of 3-3-4 or without spaces?Send Diagnosis Codes (Y/N)?Do you want to send an events diagnosis codes in an OBX segment?Send “Copy To” Location (Y/N)?Default is NO. If set YES this will populate an extra OBX segment OBX:3.1 and OBX3.2 with the exam code and the “Copy To” location

UNVERIFIED REPORTS (Y/N)?

Do you want to receive unverified reports?PID:3 ASSIGNING AUTHORITY

In PID:3 what assigner are you going to use for your primary key (example RN1)?Send results for sitesBy default results for all sites are sent to the ordering system. The system may be configured to send results only for a list of specific sites.

Report Right MarginBy default reports are sent as is. If the remote system cannot process long lines a right margin can be


specified

Document Control

Title RIS_PD154_OCS_Owner Steve Verdon Date Created 01/06/2006File Ref. RIS_PD154_OCS_CRIS VersionChange HistoryIssue Date Author / Editor Details of Change0.1 11/05/05 Alan Shields First Draft0.2 08/06/05 Alan Shields Added NTE segment for clinical history, added mobile

phone number and email address, added MSA segment for acknowledgement messages, added event key and accession number to filler fields 1 & 2 in OBR segment.

0.3 07/07/05 Alan Shields Added site or attendance and modality to OBR segment

0.4 06/09/05 Alan Shields ORC and OBR inbound where incorrectly referring to old ORM^O01 and ORR^R01 messages, added EVN segment. Added ORC:19

0.5 16/09/05 Alan Shields Added list of observation identifiers, added two diagrams showing the relationship of fields in a message with the CRIS UI,

0.6 22/11/05 Alan Shields Added maximum size to fields, restructured segment definitions. Corrected description of outbound OBX segments.

0.7 13/03/06 Alan Shields Corrected note regarding the PID segment. This previously suggested that a patient record could be created from an order message. This is not the case.

Added note regarding user definable status codes.0.8 27/04/06 Alan Shields Description of ORC:2 for outgoing messages was

incomplete. Description of PV1:18 had inappropriate examples.

0.9 08/11/06 Steve Verdon Added configuration sheet1.0 17/11/06 Alan Shields Re-instated this document control section and the

introduction. Fixed numbering and formatting.1.1 31/07/07 Alan Shields Added Value type to inbound OBX segment, changed

examples in notes for patient type to more appropriate values.

1.2 20/02/2008 Alan Shields Corrections to PID segment.1.3 21/02/2008 Alan Shields Added placer fields1.4 27/02/2008 Alan Shields Adjusted position of arrows on the mapping diagrams

1.5 10/03/2008 Alan Shields Updated order control reason codes1.6 21/04/2008 Alan Shields Updated ordered by, technician, secretary and

radiologist fields. Added right margin and site filter to configuration questions.

1.8 27/05/2009 Steven Verdon Updated section 2.2, PD1 Inbound, ORC:16 size change, PV1 description and corrected section 8 diagrams


1.9 05/11/2009 Steven Verdon Change of wording relating to Value Type “TX” in OBX segment

1.10 21/12/2009 Neil Twist Updated for 2.09.10 functionality1.11 05/03/2010 Steven Verdon Updated 4.10 “Unsolicited Results” and added OBR:16

to outbound OBR segment.1.12 21/07/2010 Chris King Updated 4.2 with order control values.1.13 09/09/2010 Alan Shields Added image/request card transfer1.14 21/12/2010 Chris King Section 8 updated with reason for exam and clinical

safety questions.1.15 29/01/2012 Steven Verdon Urgency field in OBX (outbound)

NHS number format added to configurable items listOBX Reason field correctedOBX:14 + 16 changed to state “LAST” d&t or person (outbound)Send Diagnosis code (Y/N) added to configurable items listOBR:28 Results copies to added“Copy To” added to configurable items list

1.16 30/01/2012 Steven Verdon PV1.9 – changed “bill referrer” to “lead clinician”1.17 04/09/2012 Steven Verdon NTE segment. Field size for clinical history is 2k

Updated Review panel1.18 19/09/2012 Steven Verdon OBR:16 not used1.19 18/04/2013 Steven Verdon Document review1.20 09/12/2013 Steven Verdon Document review1.21 29/12/2014 Steven Verdon Document review1.22 31/07/2015 Steven Verdon Amended MSA definition to include “AR” code1.23 17/10/2015 Steven Verdon Addition of ORC:4 – Group Order ID for incoming

orders. NHS number check digit added for inclusion in outbound messages (optional). Inclusion of PID3.2/PID:32 for the NHS number check digit (optional). Option to remove 2099 (waiting) dates from ORC:7, OBR:27, OBR:34.2 and OBR:34.3. Inclusion of the DG1 segment

1.24 20/10/2015 Andrea Hardy Updated document template1.25 05/04/2016 Steven Verdon Inclusion of PV1.3, PV1.10 and PV1.17. Addition of

MSH:3/MSH:4 as part of the DG1 segment change. Additional patient details added (PID:10/12/15/16/17/18/26)

1.26 21/06/2016 Steven Verdon Format changes to sub items. Updated to release 2.09.10t1e (Dual OCS), added new Dual OCS section

1.27 09/08/2016 Steven Verdon Refreshed screenshots and messages to section 9 (Sample messages and mapping to the CRIS user interface)

1.28 20/01/2017 Steven Verdon Amended field sizes for PID:5 in section 12.3 (from 25/25/6 to 64/64/24).

1.29 11/08/2017 Steven Verdon Document review (up to release 2.09.10t1g). Amended a few typing errors.


1.30 11/08/2017 Steven Verdon OCS ability to cancel an order has been extended in 2.10.00. Section 4.2 “Cancel an existing Order” has been revised to reflect this change.

1.31 20/12/2017 Steven Verdon Added “Report Acknowledgment” in to section 5

Review Date August 2018


purpose · web viewif the ‘sites’ attribute isn’t configured, i.e. is null, no further site...

Documents