Purpose - Healthcare Software Solutions / Medical Software ...



RIS_PD154 TITLE \* MERGEFORMAT _OCS_CRIS Interface Specification Contents: TOC \o "1-3" \h \z \u 1.Introduction PAGEREF _Toc501520996 \h 41.1Purpose PAGEREF _Toc501520997 \h 41.2Audience PAGEREF _Toc501520998 \h 42.Implementation Model PAGEREF _Toc501520999 \h 52.1Overview PAGEREF _Toc501521001 \h 52.2Application Data Flow PAGEREF _Toc501521002 \h 52.3HL7 version PAGEREF _Toc501521003 \h 53.Dual Order Communications PAGEREF _Toc501521004 \h 64.Message & Activity Mapping – OCS to CRIS PAGEREF _Toc501521005 \h 74.1Creation of a new order PAGEREF _Toc501521008 \h 74.2Cancel an existing Order PAGEREF _Toc501521009 \h 75.Message and Activity mapping – CRIS to OCS PAGEREF _Toc501521010 \h 85.1Create an appointment for an order PAGEREF _Toc501521012 \h 85.2Patient Attends PAGEREF _Toc501521013 \h 85.3Order Cancelled PAGEREF _Toc501521014 \h 85.4Order Changed PAGEREF _Toc501521015 \h 85.5Additional examination added PAGEREF _Toc501521016 \h 85.6Examination performed PAGEREF _Toc501521017 \h 95.7Report entered PAGEREF _Toc501521018 \h 95.8Report verified PAGEREF _Toc501521019 \h 95.9Report amended PAGEREF _Toc501521020 \h 95.10Report acknowledged PAGEREF _Toc501521021 \h 95.11Unsolicited Results PAGEREF _Toc501521022 \h 105.12Status changes PAGEREF _Toc501521023 \h 106.Message Transport PAGEREF _Toc501521024 \h 116.1Connections PAGEREF _Toc501521026 \h 116.2Transport level Acknowledgements PAGEREF _Toc501521027 \h 116.3Framing Characters PAGEREF _Toc501521028 \h 117.Error handling PAGEREF _Toc501521029 \h 128.Data Mappings – OCS to CRIS PAGEREF _Toc501521030 \h 138.1Patient Identifiers PAGEREF _Toc501521033 \h 138.2Null values PAGEREF _Toc501521034 \h 138.3Segment mappings PAGEREF _Toc501521035 \h 148.3.1MSH PAGEREF _Toc501521039 \h 148.3.2MSA PAGEREF _Toc501521040 \h 158.3.3PID PAGEREF _Toc501521041 \h 168.3.4PV1 PAGEREF _Toc501521042 \h 178.3.5PD1 PAGEREF _Toc501521043 \h 188.3.6ORC PAGEREF _Toc501521044 \h 198.3.7OBR PAGEREF _Toc501521045 \h 208.3.8OBX PAGEREF _Toc501521046 \h 218.3.8.1Images PAGEREF _Toc501521047 \h 228.3.9NTE PAGEREF _Toc501521048 \h 238.3.10DG1 PAGEREF _Toc501521049 \h 249.Sample Message and mapping to CRIS user interface PAGEREF _Toc501521050 \h 2510.Data Mappings – CRIS to OCS PAGEREF _Toc501521051 \h 3110.1Time Stamp values PAGEREF _Toc501521054 \h 3110.2Messages PAGEREF _Toc501521055 \h 3110.2.1OMG^O19 Order Message PAGEREF _Toc501521058 \h 3110.2.2ORG^O20 Order acknowledgement PAGEREF _Toc501521059 \h 3110.2.3ORU^R01 Clinical Report PAGEREF _Toc501521060 \h 3211.Order control and status summary PAGEREF _Toc501521061 \h 3312.CRIS to HL7 Segment mappings PAGEREF _Toc501521062 \h 3412.1MSH PAGEREF _Toc501521065 \h 3412.2MSA PAGEREF _Toc501521066 \h 3512.3PID PAGEREF _Toc501521067 \h 3612.4PV1 PAGEREF _Toc501521068 \h 3812.5ORC PAGEREF _Toc501521069 \h 3912.6OBR PAGEREF _Toc501521070 \h 4112.7OBX PAGEREF _Toc501521071 \h 4313.CONFIGURABLE ITEMS REQUIRED BY THE INTERFACE PAGEREF _Toc501521072 \h 44IntroductionPurposeThis 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.AudienceThis document is intended for system integrators, third party suppliers and potential customers. The reader is assumed to be familiar with the HL7 standard.Implementation ModelOverviewCRIS 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.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^O19|||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^Andy||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^Andy||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 CRISMany 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.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.Dual Order CommunicationsTo 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.Message & Activity Mapping – OCS to CRISCreation of a new orderWhen a new order is entered on OCS it should send an OMG^O19 message with order control “NW”. CRIS will acknowledge receipt of this with an ORG^O20 message indicating success or failure to store the order. Note that the PID segment of the ORG^O20 message is a copy of the PID segment found in the OMG^O19 sent by OCS.Cancel an existing OrderWhen a clinician cancels a previously requested order OCS should send an OMG^O19 with order control “CA”. Orders may only be cancelled prior to them being accepted on CRIS. CRIS will return an ORG^O20 indicating success or failure of the cancellation (“OC” – order cancelled or “UC” – unable to cancel). Note that the PID segment of the ORG^O20 message is a copy of the PID segment found in the OMG^O19 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.Message and Activity mapping – CRIS to OCSCreate an appointment for an orderWhen a user on CRIS has made an appointment for an order CRIS will send an OMG^O19 message with order control set to “SC” (status change) and a status value of “SC” (scheduled)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^O19 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 listOrder CancelledA user on CRIS may decide to cancel an order, at which point CRIS will send and OMG^O19 message with order control set to “CAW” and a status of “CA”OCS should respond with an ORG^O20 with order control either set to “OC” (order cancelled) or “UC” (unable to cancel), however regardless of this the examination will not be performed. 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^O19 message with order control set to “XO” with the revised details. OCS should respond with an ORG^O20 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.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^O19 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^O20 with order control either set to “OK” (order accepted) or “UA” (unable to accept order)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^O19 message with order control set to “SC” and a status of “CM” (complete).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).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)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)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||3Unsolicited 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.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. Message Transport All Messages are transmitted over TCP/IP using MLLP.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.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.Framing CharactersStandard HL7 MLLP framing characters will be used, these are<0B> start of message<1C> end of messageIn addition MLLP requires that each message be followed by carriage return <0D>Error handlingCRIS 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.Data Mappings – OCS to CRISPatient 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.SequenceNameUsage1ID NumberPatient Identifier2Check DigitOptional, 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) 4Assigning Authority“NHS” for NHS number“CHI” for CHI (Community Health Index) numberOtherwise the code identifying a hospital for hospital numbers. 5Identifier Type Code“NH” for NHS number/ CHI number“MR” for hospital numbersNull valuesIf a field is not supported it should not be sent, where a blank or null value is held it should be sent as “”.Segment mappingsMappings of HL7 data items to the CRIS data model. Items not mentioned here are ignored by CRIS.MSHThis segment should appear on all messages.PositionNameMax WidthUsage1Segment Delimiter1CRIS only supports the HL7 default segment delimiter |2Encoding characters4CRIS only supports the HL7 default encoding characters ^~\&3Sending Application24Stored if present along with DG1 segment data4Sending Facility12Stored if present along with DG1 segment data. 9Message TypeBoth message type and trigger type are mandatory.9.1Message Type39.2Trigger Event310Message Control ID20Used to uniquely identify the message, this value will be returned in MSA:2 of any acknowledgements.12Version ID3CRIS supports the 2.4 version of the HL7 specificationMSAThis segment should appear on ORG^O20 messagesPositionNameMax WidthUsage2Message Control ID10The ID of the order message being responded to PIDThe 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.PositionNameMax WidthUsage3Patient ID (Internal)Refer to the notes on patient identifiers above.3.1ID153.2Check Digit2Optional3.4Assigning Authority53.5Identifier type code2PV1For CRIS the PV1 segment is only relevant for new order messages. For other messages it is ignored.PositionNameMax WidthUsage3Assigned Patient Location15Current patient location / ward9Consulting Doctor8The consultant in charge of the patient. This will be mapped to the lead clinician on CRIS. Only <ID Number> is used.10Hospital Service64Episode description17Admitting Doctor24Admitting Doctor / Physician18Patient Type1Patient 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.19Visit Number30Episode identifier from OCS. New orders booked on CRIS as being additional to this order will be sent with the same value.PD1PD1 is not referenced as part of an Order message.PositionNameMax WidthUsage3.3Patient Primary facility9Patients registered GP practice.<id number> should contain the national GP practice code.Note that <id number> is the third sub component.4Patient Primary care provider and name10<id number> should contain the national code for the patients registered GPORCThe ORC segment should appear on OMG^O19 and ORG^O20 messages.PositionNameMax WidthUsage1Order Control2Identifies the type of order message. Possible values are“NW” New Order (OMG^O19)“CA” Cancel Order (OMG^O19)“OC” Order Cancelled (ORG^O20)“UC” Unable to Cancel (ORG^O20)“XR” Order Changed (ORG^O20)“UX” Unable to Change (ORG^O20)2Placer Order Number30Unique order ID allocated by OCS, only <Entity Identifier> is used.3Filler Order Number10Unique 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.4Placer Group Number22Optional, 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.9Date/TimeOf Transaction26The date and time that the order was placed.10Entered ByThe person who entered the order. 10.2Family Name32<family name> is appended to <given name> and <middle initial> components. Any characters passed the max width will be truncated10.3Given Name12Ordering Provider15The clinician responsible for entering the request, this field maps to the referrer field on CRIS. Only <id number> is used.13Enterers Location15This maps to the ward field on CRIS. Only <point of care> is used.16Order Control Code Reason50For acknowledgements and cancellations CRIS will log the value of the <text> component17Entering Organization8<identifier> should contain the specialty of the ordering clinician.19Action ByShould 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 field21Ordering facility Name9<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.OBRThe OBR segment should appear on OMG^O19 new order messages. For other messages it is ignored.PositionNameMax WidthUsage4Universal Service ID8The examination being requested. Only <identifier> is used.18Placer Field 140This value will be returned on subsequent response messages from CRIS for this order.19Placer Field 240This value will be returned on subsequent response messages from CRIS for this order.27Quantity/Timing26<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.30Transportation Mode1Transportation mode for this patient. This field may require translation, refer the CRIS installation on site for actual values.OBXOBX 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.PositionNameMax Width2Value Type2 – Must be TX3Observation Identifier305Observation ValueDependent on observation value – see belowThe following observation identifiers are recognized by CRISIDMax WidthDescriptionLMP8Date of patients last menstrual period, this should be in the format YYYYMMDDPREGNANT1Whether or not the patient may be pregnant, values should be Y,N or blankCATEGORY1Request category, If this is not supplied CRIS will default the value based on the ward codeSITE5Site the order is to be performed at, If this is not supplied CRIS will default the value based on the ward code. PATHWAY32The Pathway ID associated with this order.CONTACT NUMBER25The contact number for the orderREASON2048The 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 storedQUESTIONSClinical Information – added to the clinical safety questionsRENAL FUNCTIONClinical Information – added to the clinical safety questionsCREATININE LEVELClinical Information – added to the clinical safety questionsCREATININE DATEClinical Information – added to the clinical safety questionsRESULTSClinical Information – added to the clinical safety questionsImagesAs 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 followsObservation Identifier<Identifier> should contain the data type – eg REQCARD for request cardObservation 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 64NTENTE segments may be present in order to send clinical history text.PositionNameMax WidthNotes1Set ID4Sequence, first NTE in a message should be 1, followed by 2 etc.3Comment2kEach comment section should contain 1 line of the clinical history.The max width of 2k refers to the total size of the clinical history. DG1DG1 segments may be present in order to send diagnosis information. Note: Please contact HSS to discuss using this segmentPositionNameMax WidthNotes3.1Diagnosis code30Diagnosis code3.2Description64Description3.3Coding system30Coding system5Diagnosis date/timeDiagnosis date/time6Diagnosis type1Diagnosis type15Diagnosis priority1Diagnosis priority16.1Diagnosing clinician24Diagnosing clinician17Diagnosing classification1Diagnosis classification18Confidential1Confidential indicator (Y or N, any other value will be stored as blank)19AttestationAttestation dateSample 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|G804275430143457620369506557150-15342165222005842656581704389071585240022063216522300ORC|NW|HSS000000035||GRP12345|SC||||201607271200|RA00222^SMITH^HELEN||C911|1723923647300HSS01AED||||100||RA00222||^^HSS01320921764000792869149060005722371864OBR||||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 1674881105536900-9203417814900Site 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:13MSH|^~\&|OCS|LIVE|||||OMG^O19|1234567890||2.4PID|1||45502HSS^^^HSS^MR5170191360400751574143306002078930360500PV1|||HSS01AED||||||C911|EPISODE DESCRIPTION|||||||G8042754|G|EPI12345963950477300PD1|||^^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 1MSH|^~\&|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 4-507391496960NTE|5||LINE 5DG1|||TEST^TEST DIAGNOSIS CODE^TEST||201607271200|A|||||||||1|C999|D|N|2016072710002285406-81800OBX|1|TX|IV||NOOBX|2|TX|O2||YESOBX|3|TX|CATEGORY||NOBX|4|TX|REASON||Reason for exam line 1OBX|5|TX|QUESTIONS||Question 1MSH|^~\&|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||^^HSS01-8023529081000OBR||||CFOOR||||||||||||||MISCELANEOUS1|MISCELANEOUS2||||||||^^^201607271200^^1|||WNTE|1||CLINICAL INFO LINE 1NTE|2||ADDITIONAL INFO ON LINE 2NTE|3||LINE 3NTE|4||LINE 4122443615986500NTE|5||LINE 5DG1|||TEST^TEST DIAGNOSIS CODE^TEST||201607271200|A|||||||||1|C999|D|N|201607271000-802351097800OBX|1|TX|IV||NOOBX|2|TX|O2||YESOBX|3|TX|CATEGORY||NOBX|4|TX|REASON||Reason for exam line 1OBX|5|TX|QUESTIONS||Question 113106402730500MSH|^~\&|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||YES-34506152244OBX|3|TX|CATEGORY||N255341916258400-25400169281OBX|4|TX|REASON||Reason for exam line 1223424216429700OBX|5|TX|QUESTIONS||Question 1Data Mappings – CRIS to OCSTime Stamp valuesCRIS 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.Messages CRIS sends three messages, OMG^O19, ORG^O20 and ORU^R01. OMG^O19 Order MessageThe 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.CodeMessage TypeNWNew order booked on CRISCACancellation of an existing orderXOChange order requestSCStatus ChangedORG^O20 Order acknowledgementThe order acknowledgement message is sent in response to received new orders and order cancellation messages. ORC:1 defines the type of acknowledgementCodeMessage TypeOCOrder cancelled UCUnable to cancel OKOrder Accepted OKUAUnable to accept orderORU^R01 Clinical ReportThe 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 missingRight 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 ordersThis person can neither walk nor writeLeft footLeft foot appears to be missingRight armThe right arm is mostly complete; however the patient is missing four fingers and a thumb.Order control and status summaryThe following table lists the order control and status value combinations that will be produced by CRIS.Message TypeOrder ControlStatusMeaningOMG^O19NWSCNew order booked on CRIS, appointment bookedIPNew order booked on CRIS, patient in dept.SCSCStatus change, appointment bookedIPStatus change, patient in dept.CMStatus change, examination performedCACAOrder cancelledXOSCOrder changed, appointment bookedIPOrder changed, patient in ^O20OKn/aAcknowledgement for new order, okUAn/aAcknowledgement for new order, order not acceptedOCn/aAcknowledgement for cancellation, cancelled.UCn/aAcknowledgement for cancellation, order not cancelled.ORU^R01SCCMClinical reportCRIS to HL7 Segment mappingsMSHMSH appears on all messagesPositionNameMax WidthNotes1Field Separator1Always Populated with “|”2Encoding Characters4Always Populated with “^~\&”3Sending Application180Defaults to “CRIS” may be configured to send any fixed value.4Sending Facility180Defaults to “LIVE” may be configured to send any fixed value.5Receiving Application180Default is empty, may be configured to send any fixed value.6Receiving Facility180Default is empty, may be configured to send any fixed value.7Date Time of Message26Populated 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.9Message TypeThe type of the message. CRIS sends the messagesOMG^O19ORG^O20ORU^R019.1Message Type39.2Trigger Event310Message Control ID20Populated with a unique id for the message11Processing ID1Set to “P”12Version ID3Set to “2.4”MSAThis segment will appear on ORG^O20 messagesPositionNameMax WidthUsage1Acknowledgement Code2Will 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.2Message Control ID20The ID of the order message being responded toPIDPID 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.PositionNameMax WidthNotes3Patient ID InternalWill contain a list of the patient identifiers known by CRIS, refer to the notes on patient identifiers.3.1ID153.2Check Digit2Optional, 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.4Assigning Authority53.5Identifier Type Code25Patient NameOnly the first occurrence is populated.5.1Family Name64<Family Name> is populated with surname from CRIS.5.2Given Name64Forenames 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.3Middle Initial5.4Prefix24patients title is placed in <prefix>7Date Time Of Birth26Patients date of birth, only century, year, month and day are populated8Patient Sex1This field may require translation, values on CRIS areF FemaleM MaleI IndeterminateU Unknown10Race3Patient’s race. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE11AddressCRIS has four lines of address plus post code.11.1Street Address50The first line is placed in <street address>11.2Other Designation50The second line is placed in <other designation>11.3City35The third line is placed in <city>11.4State35The Fourth line is placed in <province>11.5Zip or postal Code8The two components of post code are combined and placed in <zip or postal code>12County Code9County code. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE13Phone number homePatients home telephone number, email address and mobile number.Mobile telephone number is placed in the next repeating instanceEg|0115874245^^^support@~07785342542|13.1Phone Number25Home Telephone number13.4Email Address40Email address14Phone number business25Patients work telephone number15Primary Language3Patient’s primary language. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE16Marital Status1Marital status. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE17Religion3Religion. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE18Patient Account Number20Patient Account Number. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE22Ethnic Group2This field may require translation26Citizenship3Citizenship. Only populated if SendAdditionalPatientInfo is TRUE. By default this is FALSE29Patient Death Date and Time26For Deceased patients this will contain the date of death, century, year, month and day are present. Otherwise this field will contain null (“”)30Patient Death Indicator1For deceased patients this field will contain “Y” otherwise it will be “N”32Identity Reliability Code2Optional, 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)PV1The PV1 segment is only present for ORU and OMG messages.PositionNameMax WidthUsage18Patient Type119Visit Number30Episode 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.ORCThis is present on all messages.PositionNameMax WidthNotes1Order Control2Populated according to order control and status summary table above.2Placer Order Number30Contains the placer order number received in the original new order message. In unsolicited result messages this field will be blank.3Filler Order Number10Contains the CRIS allocated order id.5Order status2Populated according to order control and status summary table above.7Quantity/Timing26<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.39Date Time of transaction26Date and time of the user action on CRIS that resulted in this message.10Entered ByThe user on CRIS that entered the order/status/result.10.1ID Number10populated with the ID of the user20.2Family Name40populated with the users name12Ordering Provider15<id number> is populated with the code identifying the referrer on CRIS13Enterers location15<point of care> is populated with the code identifying the ward/location on CRIS16Order control code reason2This 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 errorFor messages of type “UA” OE – Order already existsUP – Unknown patientIE – Internal Error17Entering Organization8<identifier> will contain the specialty of the ordering clinician.18Entering Device31The workstation on CRIS where the order/status/result was entered.19Action By10Identifies the user on CRIS that triggered the sending of this message. ID Number contains the CRIS user id.21Ordering facility name9<id number> will contain the code identifying the hospital / GP practice etc. that the request was made from.OBRThis is present on all messages.PositionNameMax WidthNotes2Placer Order Number30Contains 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:23Filler Order Number10Contains the CRIS allocated order id.This field contains the same value as ORC:34Universal Service ID8<identifier> contains the examination procedure code from CRIS. <text> contains the examination procedure name from CRIS.18Placer Field 140Will be populated with whatever value was received in Placer Field 1 of the original NW order message.19Placer Field 240Will be populated with whatever value was received in Placer Field 2 of the original NW order message.20Filler Field 140CRIS generated event key. OCS may use this field to identify which orders have been performed as a single attendance.21Filler Field 240CRIS 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.22Result rpt status changeDate/time26Populated on report messages onlyThis will contain the date and time that the report was typed, verified or changed (depending on result status)24Diagnostic Serv Sect ID1Populated with the modality of the examination.27Quantity/Timing26<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:7Optional, 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.328Result copies to24Details of the “Copy To” referrer in the event details32Principal Result InterpreterPopulated on report messages only32.1.1Name.ID10<id number> of <name> contains the id of the first radiologist. 32.1.2Name.FamilyName40<Family Name> of <name> contains the name of the radiologist.32.2Start Date/Time26<start date/time> contains the date & time the report was created.33Assistant Result InterpreterPopulated on report messages only33.1.1Name.ID10<id number> of <name> contains the id of the second radiologist33.1.2Name.FamilyName40. <Family Name> of <name> contains the name of the radiologist.34TechnicianPopulated on status change status “CM” messages only34.1.1Name.ID10<id number> of <name> contains the id of the radiographer that performed the procedure.34.1.2Name.FamilyName40<family name> of <name> contains the name of the radiographer that performed the procedure.34.2Start Date/Time26<start date/time> contains the date and time the procedure was performedOptional, 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.334.3End Date/TimeOptional, 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.334.5Room6<room> contains a code identifying the xray room where the procedure was performed, 34.7Facility5<facility> contains a code identifying the hospital at which the procedure was performed34.10Building8<Building> contains the department code.35TranscriptionistPopulated on report messages only35.1.1Name.ID10<id number> of <name> contains the id of the person that typed the report.35.1.2Name.FamilyName40Contains the name of the person that typed the report.35.2Start Date/Time26<start date/time> contains the date & time the report was typed.OBXOBX segments are present on clinical report messages. One OBX for each paragraph of report.PositionNameMax WidthNotes1Set ID1Set to “1”2Value Type2Set to “TX”3Observation Identifier8<identifier> contains the examination code for the order5Observation Value4kContains one paragraph of the textual report. 8Urgency1Populated 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|||||U11Observation ResultStatus1Indicates the status of the report on CRISP Preliminary reportF Final ReportC Changed report14Date & Time Of The Observation26This will contain the last date and time that the report was typed, verified or changed (depending on result status)16Responsible Observer51Either 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.CONFIGURABLE ITEMS REQUIRED BY THE INTERFACEOUTBOUND IP and PORTIP that the HSS interface will connect to and the port you will be listening on.SENDING APPLICATIONWhat value you will be putting in to MSH:3 (if any)SENDING FACILITYWhat value you will be putting in to MSH:4 (if any)RECEIVING APPLICATIONWhat value you will be putting in to MSH:5 (if any)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” locationUNVERIFIED REPORTS (Y/N)?Do you want to receive unverified reports?PID:3 ASSIGNING AUTHORITYIn 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 specifiedDocument ControlTitleRIS_PD154_OCS_ TITLE \* MERGEFORMAT CRIS Interface Specification OwnerSteve VerdonDate Created01/06/2006File Ref.RIS_PD154_OCS_ TITLE \* MERGEFORMAT CRIS Interface Specification CRIS VersionChange HistoryIssueDateAuthor / EditorDetails of Change0.111/05/05Alan ShieldsFirst Draft0.208/06/05Alan ShieldsAdded 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.307/07/05Alan ShieldsAdded site or attendance and modality to OBR segment0.406/09/05Alan ShieldsORC and OBR inbound where incorrectly referring to old ORM^O01 and ORR^R01 messages, added EVN segment. Added ORC:190.516/09/05Alan ShieldsAdded list of observation identifiers, added two diagrams showing the relationship of fields in a message with the CRIS UI, 0.622/11/05Alan ShieldsAdded maximum size to fields, restructured segment definitions. Corrected description of outbound OBX segments.0.713/03/06Alan ShieldsCorrected 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.827/04/06Alan ShieldsDescription of ORC:2 for outgoing messages was incomplete. Description of PV1:18 had inappropriate examples.0.908/11/06Steve VerdonAdded configuration sheet1.017/11/06Alan ShieldsRe-instated this document control section and the introduction. Fixed numbering and formatting.1.131/07/07Alan ShieldsAdded Value type to inbound OBX segment, changed examples in notes for patient type to more appropriate values.1.220/02/2008Alan ShieldsCorrections to PID segment.1.321/02/2008Alan ShieldsAdded placer fields1.427/02/2008Alan ShieldsAdjusted position of arrows on the mapping diagrams1.510/03/2008Alan ShieldsUpdated order control reason codes1.621/04/2008Alan ShieldsUpdated ordered by, technician, secretary and radiologist fields. Added right margin and site filter to configuration questions.1.827/05/2009Steven VerdonUpdated section 2.2, PD1 Inbound, ORC:16 size change, PV1 description and corrected section 8 diagrams1.905/11/2009Steven VerdonChange of wording relating to Value Type “TX” in OBX segment1.1021/12/2009Neil TwistUpdated for 2.09.10 functionality1.1105/03/2010Steven VerdonUpdated 4.10 “Unsolicited Results” and added OBR:16 to outbound OBR segment.1.1221/07/2010Chris KingUpdated 4.2 with order control values.1.1309/09/2010Alan ShieldsAdded image/request card transfer1.1421/12/2010Chris KingSection 8 updated with reason for exam and clinical safety questions.1.1529/01/2012Steven VerdonUrgency 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 list1.1630/01/2012Steven VerdonPV1.9 – changed “bill referrer” to “lead clinician”1.1704/09/2012Steven VerdonNTE segment. Field size for clinical history is 2kUpdated Review panel1.1819/09/2012Steven VerdonOBR:16 not used1.1918/04/2013Steven VerdonDocument review1.2009/12/2013Steven VerdonDocument review1.2129/12/2014Steven VerdonDocument review1.2231/07/2015Steven VerdonAmended MSA definition to include “AR” code1.2317/10/2015Steven VerdonAddition 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 segment1.2420/10/2015Andrea HardyUpdated document template1.2505/04/2016Steven VerdonInclusion 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.2621/06/2016Steven VerdonFormat changes to sub items. Updated to release 2.09.10t1e (Dual OCS), added new Dual OCS section1.2709/08/2016Steven VerdonRefreshed screenshots and messages to section 9 (Sample messages and mapping to the CRIS user interface)1.2820/01/2017Steven VerdonAmended field sizes for PID:5 in section 12.3 (from 25/25/6 to 64/64/24).1.2911/08/2017Steven VerdonDocument review (up to release 2.09.10t1g). Amended a few typing errors.1.3011/08/2017Steven VerdonOCS 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.3120/12/2017Steven VerdonAdded “Report Acknowledgment” in to section 5Review DateAugust 2018 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download