syngo® workflow slr vb10a · 2020. 7. 10. · medseries4 (ms4), unity, or soarian financials. this...

syngo® Workflow SLR VB10A

Restricted © SIEMENS AG / Siemens Medical Solutions USA, Inc., 2006, 2013. All rights reserved.

Global Siemens Headquarters Siemens AG Wittelsbacherplatz 2 80333 Muenchen Germany Global Siemens Healthcare Headquarters Siemens AG Healthcare Sector Henkestrasse 127 91052 Erlangen Germany Phone:+49 9131 84-0 www.siemens.com/healthcare Legal Manufacturer Siemens AG Wittelsbacherplatz 2 DE-80333 Muenchen Germany All product designations and company names are trademarks or registered trademarks of the corresponding companies.

Siemens reserves the right to modify the design and specifications contained herein without prior notice.

Some of the specifications described herein may not be currently available in all countries. Please contact your local Siemens Sales representative for the most current information.

The software described herein is CE-compliant in accordance with Directive MDD 93/42/EEC Annex VII of June 14th, 1993.

Restricted © SIEMENS AG / Siemens Medical Solutions USA, Inc., 1999, 2013. All rights reserved.

Siemens syngo Workflow SLR VAB10A Generic HIS Interface Mapping Guide

Intended Use Statement The information system syngo® Workflow SLR is a digital radiology information system (RIS) with integrated modules for patient administration, examination, reporting, statistics and system administration. The system electronically displays stores, retrieves, transfers, exchanges, and prints Radiology orders, results, and reports in inpatient, outpatient, and non-patient settings1, and is intended to provide information to support clinicians' and other authorized providers' patient care activities.

Through the use of industry standard protocols like HL7 and DICOM via commercially-available interface engines, syngo Workflow exchanges information with Radiology modalities and other clinical systems responsible for patient registration, order entry, and external billing systems without altering the function or parameters of any connected medical devices.

It is not intended to treat disease or administer any medicinal substances or drugs. There is no contact between device and patient. syngo® Workflow SLR can be used as a separate RIS, interfacing to a Hospital Information System (HIS) or Picture Archiving and Communication Systems (PACS). It supports the reporting requirements of accreditation and regulatory agencies.

Trademarks Siemens® and syngo® are registered trademarks of Siemens AG.

VMware® is a registered trademark of VMware, Inc.

Red Hat® Enterprise Linux® is a registered trademark of Red Hat, Inc.

Microsoft, Windows, Silverlight, and SQL Server are registered trademarks of Microsoft Corporation in the United States and other countries.

Easysoft is a registered trademark of Easysoft Limited.UNITY® is a registered trademark of Siemens Medical Solutions USA, Inc.

INVISION® is a registered trademark of Siemens Medical Solutions USA, Inc.

MedSeries4® is a registered trademark of Siemens Medical Solutions USA, Inc.

Soarian® is a registered trademark of Siemens Medical Solutions USA, Inc.

Siemens OpenLink™ is a trademark of Siemens Medical Solutions USA, Inc.

Dictaphone® and PowerScribe® are registered trademarks of Nuance Communications, Inc.

Boomerang®/Enterprise Express® are registered trademarks of Nuance Communications, Inc.

Interlink Electronics® is a registered trademark of Interlink Electronics.

Lanier® is a registered trademark of Lanier Worldwide, Inc.

HL7® is a registered trademark of Health Level Seven, Inc.

This product incorporates the Breast Imaging Reporting and Data Systems (BI-RADS®) ATLAS of the American College of Radiology, Copyright 1992, 1993, 1995, 1998, 2003. The developer of this product

1 Non-patient settings are defined by Medicare where the samples are collected by another provider (doctor's office) and when they arrive in the lab they are tested and results and reports are returned to the provider who collected the sample.

Page 3 of 205 Restricted © SIEMENS AG / Siemens Medical Solutions USA, Inc., 1999, 2013.

All rights reserved. VB10A


is independently owned and operated, and is not an affiliate of the American College of Radiology. The American College of Radiology is not responsible for the contents or operation of this product or its associated software, and expressly disclaims any and all warranties, expressed or implied, in connection therewith.

Copyright Restricted © SIEMENS AG / Siemens Medical Solutions USA, Inc., 2006, 2013. All rights reserved. The following are copyrights of their respective companies or organizations:

Telerik RadControls for Silverlight (Telerik), Microsoft SQL Server 2012 (Microsoft Corporation), RichTextBox V3.5.0 Developer Build 1 (CuteSoft), EasyByte Software RTF to HTML (EasyByte Software), Dundas Chart Webpart (Dundas Data Visualization, Inc), Dragon SDK Client Edition 9 and Dictaphone PowerScribe SDK (Nuance Communications, Inc.), Atalasoft (Atalasoft, Inc.)

Portions of this product were created using LEADTOOLS ©1991-2002, LEAD Technologies, Inc. ALL RIGHTS RESERVED.

No part of this publication may be reproduced, transmitted, transcribed, stored in retrieval systems, or translated into any language or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of Siemens Medical Solutions USA.

Any reports or other figures that appear in this manual are merely illustrative and do not contain names of or data on real people. Any similarity names of people, living or dead, or in data is strictly coincidental and is expressly disclaimed.

The information contained in this manual is subject to change. Revisions and updates will be issued from time to time to document changes and/or additions.

It is confidential and proprietary to Siemens and includes information on works by Siemens' suppliers or open source organizations; in which works these suppliers or organizations claim copyright. This documentation may only be used in strict accordance with the terms of the license agreement(s) governing its use.

Warranty Information Siemens does not warrant that the material contained in its documentation is error-free. Documentation supplied to Siemens by third parties and included with his documentation is not warranted for accuracy or completeness.

For product warranty information, please contact your syngo Workflow SLR Sales Representative.

Open Source Information See the syngo Workflow SLR Open Source Software and Acknowledgements manual for a complete list of open source software used and the associated license information.




What’s New in This Edition The following functional and/or technical changes and additions are included in this document.

Changes and Additions Topic References

Added support for Patient Alternate Address Topic 4.3.1 ADT Admissions, Pre-admits, Revisions, Patient Status Transfers

Added new PD1 Segment Layout (Patient Additional Demographic Segment)

Topic 6.2.17 PD1 Segment Layout (Patient Additional Demographic Segment)

Added information regarding OBR28 (Result Copies To)

Topic 4.3.7 Orders




Table of Contents 1. About the syngo Workflow SLR Generic HIS Interface Mapping Guide ........................................... 8

1.1 Intended Audience .................................................................................................................................. 8 1.2 How This Document Is Organized .......................................................................................................... 8 1.3 Conventions Used in This Manual .......................................................................................................... 9 1.4 Related Documentation........................................................................................................................... 9 1.5 Distribution Information ......................................................................................................................... 10 1.6 Questions and Suggestions .................................................................................................................. 10 2. Safety...................................................................................................................................................... 11

2.1 Warnings ............................................................................................................................................... 11 2.2 Cautions ................................................................................................................................................ 13 3. Overview ................................................................................................................................................ 15

3.1 Generic HIS Interface with syngo Workflow SLR RIS .......................................................................... 15 3.2 Special Processing ................................................................................................................................ 15 4. Inbound Transactions ........................................................................................................................... 16

4.1 HL7 Inbound Event Table (ADTs) ......................................................................................................... 16 4.2 HL7 Inbound Message Segments ......................................................................................................... 17 4.3 Fields Received Inbound....................................................................................................................... 18

4.3.1 ADT Admissions, Pre-admits, Revisions, Patient Status Transfers ............................................... 19 4.3.2 Discharges ...................................................................................................................................... 32 4.3.3 Cancel Discharges ......................................................................................................................... 35 4.3.4 Change Admission Number or Change Medical Record Number ................................................. 37 4.3.5 Swap Patients ................................................................................................................................. 39 4.3.6 Transfers ........................................................................................................................................ 40 4.3.7 Orders ............................................................................................................................................. 42 4.3.8 Cancels ........................................................................................................................................... 48 4.3.9 Add-on Order Confirmations .......................................................................................................... 50

4.4 Sample Inbound Data ........................................................................................................................... 53 4.4.1 Orders ............................................................................................................................................. 53 4.4.2 Add-On Order Response ................................................................................................................ 53

5. Outbound Transactions ........................................................................................................................ 55

5.1 HL7 Outbound Event Table .................................................................................................................. 55 5.2 HL7 Outbound User-Defined Z-Segments ............................................................................................ 55 5.3 Fields Sent Outbound ........................................................................................................................... 56

5.3.1 Add-On Order ................................................................................................................................. 57 5.3.2 Order Status Updates ..................................................................................................................... 63 5.3.3 Procedure Charges and Miscellaneous Charges (CPT Codes and Supplies)............................... 69 5.3.4 Results ............................................................................................................................................ 75 5.3.5 Image Pointers to LCR ................................................................................................................... 81

5.4 Sample Outbound Data......................................................................................................................... 87 5.4.1 Order Status Update....................................................................................................................... 87 5.4.2 Result ............................................................................................................................................. 87

6. Data Mapping ......................................................................................................................................... 90

6.1 Description of Data Mapping Table Headings ...................................................................................... 90 6.2 Data Mapping Tables ............................................................................................................................ 91

6.2.1 ACC Segment Layout ..................................................................................................................... 91




6.2.2 AL1 Segment Layout ...................................................................................................................... 92 6.2.3 DG1 Segment Layout ..................................................................................................................... 94 6.2.4 DSC Segment Layout ..................................................................................................................... 96 6.2.5 EVN Segment Layout ..................................................................................................................... 98 6.2.6 FT1 Segment Layout ...................................................................................................................... 99 6.2.7 GT1 Segment Layout ................................................................................................................... 105 6.2.8 IN1 Segment Layout ..................................................................................................................... 114 6.2.9 MRG Segment Layout .................................................................................................................. 120 6.2.10 MSA Segment Layout ................................................................................................................ 123 6.2.11 MSH Segment Layout ................................................................................................................ 124 6.2.12 NKI Segment Layout .................................................................................................................. 127 6.2.13 NTE Segment Layout ................................................................................................................. 135 6.2.14 OBR Segment Layout ................................................................................................................ 137 6.2.15 OBX Segment Layout ................................................................................................................. 152 6.2.16 ORC Segment Layout ................................................................................................................ 156 6.2.17 PD1 Segment Layout (Patient Additional Demographic Segment) ............................................ 163 6.2.18 PID Segment Layout .................................................................................................................. 165 6.2.19 PV1 Segment Layout.................................................................................................................. 180 6.2.20 ZK1 Segment Layout (User-Defined Segment) ......................................................................... 193 6.2.21 Z-Segments Overview (Inbound to syngo Workflow) ................................................................. 196




1. About the syngo Workflow SLR Generic HIS Interface Mapping Guide This document contains information about mapping a generic interface between any Hospital Information System (HIS) and the syngo® Workflow SLR Radiology Information System (RIS). A generic HIS interface can be used as long as it has mapping capabilities to match the HIS data to the Health Level 7 (HL7) segment layouts. This document provides information about how an HIS can format an HL7 interface transaction to successfully pass to the syngo Workflow SLR RIS, how syngo Workflow SLR expects certain fields within this HL7 interface transaction from an HIS to be valued, and how syngo Workflow SLR formats an HL7 interface transaction outbound to an HIS other than INVISION, Allegra, MedSeries4 (MS4), UNITY, or Soarian Financials.

This document may present information differently from other Siemens documents you may use. Please take a few minutes to read this introduction before using this document.

1.1 Intended Audience This document is intended for system and application programmers who need to reference the HL7 interface transaction layout for transactions between a generic HIS and syngo Workflow SLR. This document may also be used directly by customers who need a reference in writing their own interface maps to/from syngo Workflow and who maintain their own non-Siemens interface integration engine.

1.2 How This Document Is Organized This document contains the following topics.

Topic Description

Overview in topic 2 Provides an overview of the generic HIS interface for syngo Workflow SLR.

Inbound Transactions in topic 3 Details the events, message segments, and fields that are interfaced from a generic HIS to syngo Workflow SLR.

Outbound Transactions in topic 4 Details the events, message segments, and fields that are interfaced from syngo Workflow SLR to a generic HIS.

Data Mapping in topic 5 Provides mapping of HL7 field names to syngo Workflow SLR database table and column names.




1.3 Conventions Used in This Manual Menu items, function names, parameter names, and other user-interaction items are shown in bold letters.

Safety notices are divided into two classes that relate to potential danger: Warnings and Cautions. All safety notices are structured in three parts as follows: source of danger, consequence, and remedy.

Notes, cautions, and warnings are specially highlighted:

Note: Notes provide user information for optimum operation of the device, the software, and other relevant subjects.

Caution: Cautions indicate conditions or consequences that you should pay particular attention to when administering syngo Workflow SLR but where no direct danger for human beings or equipment is involved.

Warning: Warnings indicate a potential hazard to the health or life of patients or personnel.

1.4 Related Documentation Additional documentation may be needed about the particular HIS being used if more formatting detail is required about the HIS. This document is complete only from a syngo Workflow SLR perspective.

Note: For internal Siemens stakeholders, the following documentation may be helpful for understanding and implementing an HIS interface with syngo Workflow SLR.

Document Title Description

SLC_NRad03_DBM_Doc_Update_from_CMF_DDS Contains information about Doctor Updates from the Common Master File system to syngo Workflow SLR. The code for these doctor update transactions are included with the rest of the routines for the generic HIS interface, but the transactions are specific in coming inbound to syngo Workflow SLR from the Siemens CMF system. Therefore, the above document should be referenced for information on these types of transactions. The CMF doctor update transactions include segments not contained in this document (i.e., MFE, MFI, PRA, and STF).

syngoWorkflowSLR_CCHS_EMPI_Interface_DS Describes the use of assigning authorities, Identifier Type codes, external identifier numbers, and multi-entity processing. Useful as a reference regarding the syngo Workflow SLR processing of the following fields: MSH-4, PID-3, MRG-1, PID-18, and PV1-19.

syngoWorkflowSLR_V28.0_allergy_DFS Details the processing of allergy data from the AL1 segment.




Document Title Description

swf_VA31A_SG_HIS_Interfaces Provides a general overview and instructions for setting up an HIS with syngo Workflow SLR.

Swf_VA31A_DDS_INTF_Inbound_Intf_User_Fields This document is the Detailed Design Specification for the inbound user field Z-segment processing.

swf_VA31A_DDS_INTF_Outbound_Z-Segments This document is the Detailed Design Specification for the outbound user field Z-segment processing.

1.5 Distribution Information Please be aware that, due to business and legal considerations, updates to documentation are sent only to the customer information contact. syngo Workflow SLR manuals, user's guides and setup guides are available through the Siemens Customers-only Web site. Tip sheets and White Papers on specific topics related to syngo Workflow SLR are also available through the Customers-only Web site.

1.6 Questions and Suggestions If you have any questions or suggestions about the documentation, please send your comments to:

Siemens Medical Solutions USA, Inc. Attn: syngo Workflow SLR Department E17 Documentation Feedback – syngo Workflow SLR Generic HIS Interface Mapping Guide VB10A 51 Valley Stream Parkway Malvern, PA 19355 [email protected]



mailto:[email protected]


2. Safety Warnings indicate a potential hazard to the health or life of patients or personnel.

Cautions indicate a hazardous situation which, if not avoided, could result in minor or moderate injury.

2.1 Warnings

WARNING Incorrect configuration of interfaces between syngo Workflow and Hospital Information Systems (e.g. MS4, Unity, Allegra, INVISION, Soarian Financials, HISRIS interface) may lead to incorrect patient data being transmitted or stored.

Inefficient patient care; delays in diagnosis and treatment The user is responsible for configuring and testing all syngo Workflow interfaces to ensure they are configured correctly per the parameters listed in the specific applicable product's user documentation. (syngo Workflow, OpenLink and associated Siemens Hospital Information System)

WARNING It is possible to implement the system in a manner that degrades patient care. The system does not prevent such implementation.

Inefficient patient care, delays in diagnosis and treatment. Ensure that implementers are properly trained in system implementation. Perform testing prior to productive use of the system.

WARNING Hardware failure could result in massive loss of clinical data.

Inefficient patient care: delays in diagnosis and treatment. Ensure that you have implemented and verified backup services.




WARNING When forwarding an IDOC to another system, the document can be mislabeled or associated to the incorrect patient or study in the other system if the configuration of the interface is incorrect per the syngo Workflow User documentation.

Potential misdiagnosis or delay in treatment Ensure that document forwarding interface is correctly configured such that patient or study information correlates between the two systems - user should verify after configuration is enabled or if configuration is updated.

WARNING Clinical alerts are not intended for clinical monitoring, diagnosing or provision of treatment instructions and should not be implemented for these purposes.

Inappropriate reliance on clinical alerts for monitoring, diagnosing or treatment. Review clinical alert implementation to ensure appropriateness for intended use.

WARNING Incorrect configuration of HL7 Z-segments (user defined fields) may lead to incorrect patient data being transmitted (in outbound transactions)

Inefficient patient care; delays in diagnosis and treatment The user is responsible for configuring and testing all syngo Workflow interfaces to ensure they are configured correctly per the parameters listed in the specific applicable product's user documentation.

WARNING Incorrect configuration of HL7 Z-segments (user defined fields) may lead to incorrect patient data being stored (on inbound transactions).

Inefficient patient care; delays in diagnosis and treatment The user is responsible for configuring and testing all syngo Workflow interfaces to ensure they are configured correctly per the parameters listed in the specific applicable product's user documentation




WARNING Incorrect configuration of OpenLink Model Maps for interfaces between syngo Workflow and Hospital Information Systems (e.g. MS4, Unity, INVISION, Soarian Financials) may lead to incorrect patient data being transmitted or stored.

Inefficient patient care; delays in diagnosis and treatment. The user is responsible for configuring and testing all syngo Workflow interfaces to ensure they are configured correctly per the parameters listed in the specific applicable product's user documentation. (syngo Workflow, OpenLink and associated Siemens Hospital Information System)

WARNING When updating IDOCS that have been associated with multiple studies, critical information may be missing if user does not update the IDOC for each exam individually (e.g. if they do not understand that updates do not occur automatically for all associated studies)

Inefficient patient care; delays in diagnosis and treatment The user is responsible to update the IDOC for each study as needed.

2.2 Cautions

CAUTION Incorrect configuration of Document Writer (DOC) or Decision Logic Maintenance (DLM) documents can result in missing and/or incorrect data being displayed to the user. Configuration errors can include but are not limited to the following:

- Retrieving data from inappropriate database tables/columns;

- Errors in conditional logic.

- Improperly formatted data (e.g. truncated text)

Potential misdiagnosis or delay in treatment. Ensure that the Document Writer and Decision Logic Maintenance documents are properly configured and tested when created or updated.




CAUTION When accessing information in Portal Radiologist and a third party system (e.g. XDS, PACS, HIS, Dictation system, critical test results management) patient data displayed in the third party system may not match the data displayed in Portal Radiologist.

Potential misdiagnosis or delay in treatment User should ensure that the third party system is configured to display the patient name and identifying information. This information is prominently displayed in Portal Radiologist. User should verify that the patient information displayed in Portal Radiologist and that displayed in the third party system match.

CAUTION Incorrect configuration of DLM documents.

Potential Misdiagnosis. Ensure that the DLM documents are properly configured and tested when created or updated.

CAUTION Incorrect configuration of Document Writer.

Potential Misdiagnosis. Ensure that the Document Writer documents are properly configured and tested when created or updated

CAUTION Misinterpretation of Date.

Delay in treatment. Dates may be configured for either MM/DD/YYYY or DD/MM/YYYY format. Be aware of the date format your facility is using.




3. Overview

3.1 Generic HIS Interface with syngo Workflow SLR RIS The generic HIS interface (HISRIS) between an HIS and the syngo Workflow SLR RIS is defined as a two-way interface that can:

• Receive ADTs, Orders, Order Cancels, and Add-on Order Confirmations from an appropriately mapped HIS.

• Send outbound Order Status Updates, Charges, Add-On Orders, and Results from the syngo Workflow SLR RIS to an HIS

Siemens OPENLink is recommended as the interface engine to use for any mapping in either direction of this interface; however, it is not required. If a non-Siemens Interface Engine is used instead, this document defines the HL7 interface transaction layout that is expected when the HIS transaction enters or leaves syngo Workflow SLR. The customer is then responsible for all mapping setup and for any mapping issues that may occur. The interface engine should use a TCP/IP port connection to/from syngo Workflow SLR.

The following HIS’s already have their own unique model interfaces with syngo Workflow SLR:

• INVISION

• UNITY

• Allegra,

• MedSeries4

• Soarian Financials

Soarian Clinicals is the first HIS to use this generic interface layout. Any HIS different from these mentioned need to map their HIS data into transactions matching the HL7 segment layouts shown in this document.

3.2 Special Processing The interface should accommodate a full set of interface transactions sufficient to communicate necessary information back and forth between an HIS and syngo Workflow SLR. This interface is generic in nature and not coded strictly to any one particular HIS. Minor accommodations were built into this interface for use with Siemens Soarian Clinicals, which was the first HIS to use this interface. However, most of the data is formatted to a basic HL7 standard. If the HIS using this interface sends or receives data in different segments, fields, or components, or in a different format than described in the segment layout sections, then the HIS must build maps to send and receive the data as shown in this document to be able to use this model interface without customization.




4. Inbound Transactions

4.1 HL7 Inbound Event Table (ADTs) The inbound events are specific to the ADT transactions interfaced from an HIS to syngo Workflow SLR. The following list includes all the event types that can be received from an HIS in MSH-09.02, where the transaction type received in MSH-09.01 is “ADT”.

Event Description

A01 Admit/visit notification

A02 Transfer a patient

A03 Discharge/end visit

A04 Register a patient

A05 Pre-admit a patient

A06 Change an outpatient to an inpatient

A07 Change an inpatient to an outpatient

A08 Update patient information

A09 Patient departing

A10 Patient arriving

A11 Cancel admit/visit notification

A13 Cancel discharge/end visit




Event Description

A14 Pending admit

A15 Pending transfer

A16 Pending discharge

A17 Swap patients

A18 Merge patient information

A23 Delete a patient record

A25 Cancel pending discharge

A27 Cancel pending admit

A28 Add person information

A29 Delete person information

A31 Update person information

A32 Cancel patient arriving

A33 Cancel patient departing

A38 Cancel pre-admit

4.2 HL7 Inbound Message Segments Segments listed in the table below are all defined per the HL7 2.4 standard. The symbols used in the table that indicate whether or not a segment is repeated, reflects whether or not the HIS will allow multiple occurrences of the segment to be sent to syngo Workflow SLR, not specifically




whether the segment can be a repeating segment per HL7 standards. For example, the GT1 segment is technically a repeating segment per HL7, but syngo Workflow SLR will only be able to pull data from, at most, one of these segments from the HIS. The limitation of the number of specific segments that can be read in corresponds with the database fields available in which to store the incoming data in syngo Workflow SLR. The first four segments, MSH, EVN, PID, and PV1 must always be present on the ADT transaction. The list of optional segments afterwards is alphabetized.

Transaction ^ Event Segments

Segment Required unless Brackets [ ] around it

Segment may repeat if Braces { } around it

ADT^[Any event from the HL7 Inbound Event Table]

MSH, EVN, PID, PV1, [ACC], {[AL1]}, {[DG1]}, [GT1], {[IN1]}, {[NKI]}, {[NTE]}, {[OBX]}, [ZK1], {[ZPI]}, {[ZVI]}

ORM^O01

(Orders and Cancels)

MSH, [EVN], PID, PV1, ORC, OBR, {[ORC - OBR]}, {[NTE]}, {[ZPI]}, {[ZVI]}, {[ZOI]}, {[ZAI]}

ORR^O02

(Add-on Order Confirmations)

MSH, MSA, PID, ORC, {[ZPI]}, {[ZVI]}, {[ZOI]}, {[ZAI]}

4.3 Fields Received Inbound This section is split into transaction types that share the same type of processing inbound to syngo Workflow SLR. In each section, a table lists all the fields syngo Workflow SLR can receive.




The first column is a generic name for what the field value is. The second column is the syngo Workflow SLR table and field name where this data is stored in the syngo Workflow SLR database. The table and field name is delimited by a “.” to reflect the syntax for referencing this field in documents and requisitions output from syngo Workflow SLR. The third column contains an “R” if the field is required data for syngo Workflow SLR for the particular transaction type, an “O” if the field is optional data, or “C” if the requirement of the field is conditional. The fourth column contains the HL7 segment(s) and field(s). Refer to in the Data Mapping Table section for more detail. The fifth column contains any special comments about the field/data on that row.

4.3.1 ADT Admissions, Pre-admits, Revisions, Patient Status Transfers Note: Transaction types A01, A04, A05, A06, A07, A08, A10, A14, A28, A31.

Field Names syngo Workflow SLR Database Name

Req/ Opt

Refer to: Comments

Accident Code Pat_info_visit.acc_cd O ACC-2

Allergy Type Pat_allergy.allergy_type O AL1-2

Allergy Description Pat_allergy.allergy_desc O AL1-3

Allergy Severity Pat_allergy.allergy_severity O AL1-4

Allergy Reaction Pat_allergy.allergy_reaction O AL1-5

Allergy Onset Pat_allergy.allergy_onset O AL1-6

ICD Codes (up to 2) Pat_info_visit.icd_cd_1 Visit_info.icd_code1 Pat_info_visit.icd_cd_2 Visit_info.icd_code2

O DG1-3

Diagnosis (up to 2) Pat_info.diag1 Visit_info.diag1 Pat_info.diag2 Visit_info.diag2

O DG1-3

Arrival Date/Time Pat_info_visit.arrival_dtime O EVN-2





Req/ Opt

Refer to: Comments

EVN-3

Guarantor Number Pat_guar_visit.guar_no O GT1-2

Guarantor Name Pat_guar_visit.guar_last Pat_guar_visit.guar_first Pat_guar_visit.guar_middle Pat_guar_visit.guar_suffix Pat_guar_visit.guar_prefix Pat_guar_visit.guar_title

O GT1-3

Guarantor Address Pat_guar_visit.guar_addr1 Pat_guar_visit.guar_addr2 Pat_guar_visit.guar_city Pat_guar_visit.guar_state Pat_guar_visit.guar_zip

O GT1-5

Guarantor Phone Pat_guar_visit.guar_phone O GT1-6

Guarantor Sex Pat_guar_visit.guar_sex_1 O GT1-9

Guarantor Type Pat_guar_visit.grn_type_1 O GT1-10

Guarantor-Patient Relationship

Pat_guar_visit.guar_pt_rel_1 O GT1-11

Guarantor Social Security Number

Pat_guar_visit.guar_ssa_no_1 O GT1-12

Guarantor Employer Name

Pat_guar_visit.guar_empl_name O GT1-16

Guarantor Employer Address

Pat_guar_visit.guar_empl_addr1 Pat_guar_visit.guar_empl_addr2 Pat_guar_visit.guar_empl_city Pat_guar_visit.guar_empl_state

O GT1-17





Req/ Opt

Refer to: Comments

Pat_guar_visit.guar_empl_zip

Guarantor Employer Phone

Pat_guar_visit.guar_empl_phone O GT1-18

Insurance Number (up to 4)

Pat_ins_visit.ins_no O The ins_no loaded is the count of IN1 segments in the transaction. For example, the first IN1 segment will load “1” into ins_no with all the data for the first insurance.

Insurance Plan Code (up to 4)

Pat_ins_visit.plan_code O IN1-2

Insurance Company Name (up to 4)

Pat_ins_visit.company_name O IN1-4

Insurance Address (up to 4)

Pat_ins_visit.insur_addr1 Pat_ins_visit.insur_addr2 Pat_ins_visit.insur_city Pat_ins_visit.insur_state Pat_ins_visit.insur_zip

O IN1-5

Insurance Phone (up to 4)

Pat_ins_visit.insur_phone O IN1-7

Insurance Group (up to 4)

Pat_ins_visit.grp O IN1-8

Insurance Effective Date (up to 4)

Pat_ins_visit.eff_date O IN1-12

Insurance Coordination of Benefits (up to 4)

Pat_ins_visit.coord_of_benefit O IN1-22





Req/ Opt

Refer to: Comments

Insurance Policy Number (up to 4)

Pat_ins_visit.pol O IN1-36

Hospital/Facility Name

Patient.hosp Visit.hosp

C MSH-4 This field is required for multi-entity accounts. For accounts with only one facility, if this field is not valued, the default value loaded into the hosp field will be the value entered in the APM Receiver’s “Hospital ID” field.

Patient Employer Pat_empl_visit.pt_empr O NK1-2

Emergency Contact Name

Pat_rel.rel_last Pat_rel.rel_first Pat_rel.rel_middle Pat_rel.rel_suffix Pat_rel.rel_prefix Pat_rel.rel_title

O NK1-2

Employer-Patient Relationship

Pat_empl_visit.employer_pt_rel O NK1-3

Emergency Contact Code

Pat_rel.rel_cd O NK1-3

Employer Address Pat_empl_visit.empr_addr1 Pat_empl_visit.empr_addr2 Pat_empl_visit.empr_city Pat_empl_visit.empr_state Pat_empl_visit.empr_zip

O NK1-4

Emergency Contact Address

Pat_rel.rel_addr1 Pat_rel.rel_addr2 Pat_rel.rel_city Pat_rel.rel_state

O NK1-4





Req/ Opt

Refer to: Comments

Pat_rel.rel_zip Pat_rel.rel_country

Employer Phone Pat_empl_visit.employer_phone O NK1-5

Emergency Contact Phone

Pat_rel.rel_phone O NK1-5

Height Pat_info_visit.pt_height O OBX-3 OBX-5 OBX-6

Weight Pat_info_visit.pt_weight O OBX-3 OBX-5 OBX-6

Medical Record Number

Patient.pt_med_rec_no Patient.pt_med_rec_no_ext Patient.pt_med_rec_no_chk_digit Patient.mrn_assign_auth_cd

R PID-3 The Medical Record Number would always be pulled from this field. The Admission Number will be pulled from this field, if the HIS values it here. Otherwise, the Admission Number will be pulled from PID-18. The Visit Number, if valued, will be pulled from this field, if the HIS values it here. Otherwise, the Visit Number will be pulled from PV1-19. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “MR”, then that occurrence of this PID-3 field will be used for the related Medical Record Number values. The raw data received from component 1 of this field is loaded directly into patient.pt_med_rec_no_ext, as is, where “ext” stands for “external”. This field is stored so this HIS-originated value can be sent back on outbound transactions exactly as it was received, so exactly how the HIS expects it. If any check digit is received from the HIS, this value is stored directly into patient.pt_med_rec_no_chk_digit, so it can easily be determined on outbound processing whether or not a check digit was present prior to concatenation to create the syngo





Req/ Opt

Refer to: Comments

Workflow SLR patient.pt_med_rec_no value. The patient.pt_med_rec_no field is valued by pulling component 1 of this field, concatenating it with any 1-digit check digit value that may optionally be present in component 2 of this field, and then zero-filling the concatenated value to a 12-digit number. The value stored in this format is used for syngo Workflow SLR screens and processing. Component 4 of this field is stored in patient.mrn_assign_auth_cd to save the assigning authority that may have been associated with this Medical Record Number. NOTE: Although the pt_med_rec_no_ext column is defined in the patient table as a varchar(64), syngo Workflow can still only support medical record numbers of maximum length of 12, including a check digit, if any.

Corporate ID Pat_corp.corp_id Pat_corp.corp_id_ext Pat_corp.corp_id_chk_digit Pat_corp.corp_id_assign_auth_cd

C PID-3 If a multi-entity site and the patient is associated with a specific corporate ID, this data should be received. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “EE”, then that occurrence of this PID-3 field will be used for the related Corporate Identifier values. The raw data received from component 1 of this field is loaded directly into pat_corp.corp_id_ext, as is, where “ext” stands for “external”. This field is stored so this HIS-originated value can be sent back on outbound transactions exactly as it was received, so exactly how the HIS expects it. If any check digit is received from the HIS, this value is stored directly into pat_corp.corp_id_chk_digit, so it can easily be determined on outbound processing whether or not a check digit was present prior to concatenation to create the syngo Workflow SLR pat_corp.corp_id value. The pat_corp.corp_id field is valued by pulling component 1 of this field, concatenating it with any 1-digit check digit value that may optionally be present in component 2 of this field, and then





Req/ Opt

Refer to: Comments

zero-filling the concatenated value to a 12-digit number. The value stored in this format is used for syngo Workflow SLR screens and processing. Component 4 of this field is stored in pat_corp.corp_id_assign_auth_cd to save the assigning authority that may have been associated with this Patient Corporate Identifier. NOTE: Although the corp_id_ext column is defined in the pat_corp table as a varchar(64), syngo Workflow can still only support corp ID numbers (also known as EMPI numbers) of maximum length of 12, including a check digit, if any.

Admission/Account Number

Visit.pt_adm_no Visit.pt_adm_no_ext Visit.pt_adm_no_chk_digit Visit.pt_adm_no_assign_auth_cd

R PID-3 or PID-18; MRG-1

syngo Workflow SLR will first try to pull the Patient Admission Number from PID-3. If the Admission Number is not sent by the HIS in PID-3, the field will optionally be pulled from PID-18. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “PN”, then that occurrence of this PID-3 field will be used for the related Admission Number values. The raw data received from component 1 of this field is loaded directly into visit.pt_adm_no_ext, as is, where “ext” stands for “external”. This field is stored so this HIS-originated value can be sent back on outbound transactions exactly as it was received, so exactly how the HIS expects it. If any check digit is received from the HIS, this value is stored directly into visit.pt_adm_no_chk_digit, so it can easily be determined on outbound processing whether or not a check digit was present prior to concatenation to create the syngo Workflow SLR visit.pt_adm_no value. The visit.pt_adm_no field is valued by pulling component 1 of this field, concatenating it with any 1-digit check digit value that





Req/ Opt

Refer to: Comments

may optionally be present in component 2 of this field, and then zero-filling the concatenated value to a 12-digit number. The value stored in this format is used for syngo Workflow SLR screens and processing. Component 4 of this field is stored in visit.pt_adm_no_assign_auth_cd to save the assigning authority that may have been associated with this Patient Admission Number. A06 and A07 events will also use MRG-1, with the same component descriptions, to identify the old Patient Admission Number on a Patient Status Transfer transaction. NOTE: Although the pt_adm_no_ext column is defined in the visit table as a varchar(64), syngo Workflow can still only support admission numbers of maximum length of 12, including a check digit, if any.

Visit Number Visit.pt_visit_no Visit.pt_visit_no_ext Visit.pt_visit_no_chk_digit Visit.pt_visit_no_assign_auth_cd

O PID-3 or PV1-19

syngo Workflow SLR will first try to pull the Patient Visit Number from PID-3. If the Visit Number is not sent by the HIS in PID-3, the field will optionally be pulled from PV1-19. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “VN”, then that occurrence of this PID-3 field will be used for the related Visit Number values. The raw data received from component 1 of this field is loaded directly into visit.pt_visit_no_ext, as is, where “ext” stands for “external”. This field is stored so this HIS-originated value can be sent back on outbound transactions exactly as it was received, so exactly how the HIS expects it. If any check digit is received from the HIS, this value is stored directly into visit.pt_visit_no_chk_digit, so it can easily be determined on outbound processing whether or not a check digit was present prior to concatenation to create the syngo





Req/ Opt

Refer to: Comments

Workflow SLR visit.pt_visit_no value. The visit.pt_visit_no field is valued by pulling component 1 of this field, concatenating it with any 1-digit check digit value that may optionally be present in component 2 of this field, and then zero-filling the concatenated value to a 12-digit number. The value stored in this format is used for syngo Workflow SLR screens and processing. Component 4 of this field is stored in visit.pt_visit_no_assign_auth_cd to save the assigning authority that may have been associated with this Patient Visit Number. NOTE: Although the pt_visit_no_ext column is defined in the visit table as a varchar(64), syngo Workflow can still only support visit numbers of maximum length of 12, including a check digit, if any.

Social Security Number

Patient.pt_ss_no O PID-3

Valid Social Security Numbers have no check digits, so component 2 is not pulled for this value. Component 4 for an assigning authority is also not pulled for this value since all Social Security Numbers are solely issued by the U.S. Government.

User Field Identifier Patient.user_defined_key Patient.user_key_assign_auth_cd

O PID-3 A user-defined value can be sent by the HIS and pulled from this field into the sygno Workflow patient.user_defined_key field. Any valued assigning authority received in component 4 with this value is stored in patient.user_key_assign_auth_cd.

Patient Name Pat_name.pt_first Pat_name.pt_last

R PID-5

Patient Name Pat_name.pt_middle Pat_name.pt_suffix Pat_name.pt_prefix Pat_name.pt_title

O PID-5

Birthdate Pat_name.pt_birth_dtime R PID-7





Req/ Opt

Refer to: Comments

Sex Pat_name.pt_sex R PID-8

Race Pat_info.pt_race O PID-10

Patient Address Pat_demo.pt_addr1 Pat_demo.pt_addr2 Pat_demo.pt_city Pat_demo.pt_state Pat_demo.pt_zip Pat_demo.pt_country

O PID-11

Patient Alternate Address

Pat_demo.alt_addr1 Pat_demo.alt_addr2 Pat_demo.alt_city Pat_demo.alt_state Pat_demo.alt_zip Pat_demo.alt_country

O PID-11 Second repeating segment

Home Phone Pat_demo.pt_phone O PID-13

Alternate Phone Pat_demo.alt_phone O PID-13 Second repeating Field

Work Phone Pat_info.pt_work_phone O PID-14

Marital Status Pat_info.pt_marital_sts O PID-16

Religion Pat_info_visit.pt_rel O PID-17

Death Date/Time Pat_info.pt_death_dtime O PID-29

Death Indicator Pat_info.pt_death_ind O PID-30 Should be valued as “Y” or “N”, if valued.

Patient Class Pat_info.pt_class Visit_info.pt_class

O PV1-2 Should always be valued, but is not verified for a value

Patient Location (Nurse Station,

Visit_info.pt_ns O PV1-3 Should always be valued for inpatients (patient class = “I”), but not verified





Req/ Opt

Refer to: Comments

Room/Bed) Visit_info.pt_rm_bed

Attending Doctor

Visit_info.atn_dr_no Visit_info.atn_dr_last Visit_info.atn_dr_first Visit_info.atn_dr_middle Visit_info.atn_dr_suffix Visit_info.atn_dr_prefix Visit_info.atn_dr_title Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

O PV1-7 Visit_doctor.dr_type is stored as “AT”. Especially on new admissions, it is advised the HIS send syngo Workflow SLR the attending doctor number and the attending doctor’s last and first names so there is always at least one doctor reference for a patient. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Master. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.

Referring Doctor Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

O PV1-8 Visit_doctor.dr_type is stored as “RF”. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Table. Otherwise, the doctor name and address is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.

Consulting Doctor Visit_doctor.dr_no O PV1-9 Visit_doctor.dr_type is stored as “CN”.





Req/ Opt

Refer to: Comments

Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Master. Otherwise, the doctor name and address is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.

Hospital Service Visit_info.hosp_svc O PV1-10

Alternate/Admitting Doctor

Visit_info.alt_dr_no Visit_info.alt_dr_last Visit_info.alt_dr_first Visit_info.alt_dr_middle Visit_info.alt_dr_suffix Visit_info.alt_dr_prefix Visit_info.alt_dr_title Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

O PV1-17 Visit_doctor.dr_type is stored as “AL”. Especially on new admissions, it is advised the HIS send syngo Workflow SLR the attending doctor number and the attending doctor’s last and first names so there is always at least one doctor reference for a patient. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Master. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.

Patient Type Pat_info.pt_type Visit_info.pt_type

O PV1-18





Req/ Opt

Refer to: Comments

Financial Class Pat_info.pt_fc O PV1-20

Admission Date/Time

Visit.pt_adm_dtime Pat_info.pt_adm_dtime

O PV1-44 If no date/time is received from the HIS, the current date/time will be used when valuing the syngo Workflow SLR field.

Occupation Pat_info.pt_occu O ZK1-23

Employer ID Pat_empl_visit.empr_id O ZK1-23

Patient-level User Field Type

Pat_usr_flds.type

O ZPI-1

Patient-level User Field Dates

Pat_usr_flds.date_1 Pat_usr_flds.date_2

O ZPI-3 ZPI-4

Patient-level User Fields

Pat_usr_flds.usr_fld_1 Pat_usr_flds.usr_fld_2 Pat_usr_flds.usr_fld_3 Pat_usr_flds.usr_fld_4

O ZPI-5 ZPI-6 ZPI-7 ZPI-8

Visit-level User Field Type

Visit_usr_flds.type O ZVI-1

Visit-level User Field Dates

Visit_usr_flds.date_1 Visit_usr_flds.date_2

O ZVI-3 ZVI-4

Visit_level User Fields

Visit_usr_flds.usr_fld_1 Visit_usr_flds.usr_fld_2 Visit_usr_flds.usr_fld_3 Visit_usr_flds.usr_fld_4

O ZVI-5 ZVI-6 ZVI-7 ZVI-8




4.3.2 Discharges Note: Transaction types: A03, A09, A11, A17, A23, A27, A29, A32, A38.

Field Name syngo Workflow SLR Database Name

Req/ Opt

Refer to: Comments

Hospital / Facility Patient.hosp Visit.hosp

C MSH-4 Accepted only for multi-entity patient lookup. Database field not modified.


Patient.pt_med_rec_no

C PID-3 Accepted on discharges only for patient lookup, not for storage into the syngo Workflow SLR database. Either the Medical Record Number, OR the Admission plus a Visit Number, must be valued on the transaction as a whole. The Medical Record Number would always be pulled from this field. The Admission Number will be pulled from this field, if the HIS values it here. Otherwise, the Admission Number will be pulled from PID-18. The Visit Number, if valued, will be pulled from this field, if the HIS values it here. Otherwise, the Visit Number will be pulled from PV1-19. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “MR”, then that occurrence of this PID-3 field will be used for the related Medical Record Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.


Visit.pt_adm_no

R PID-3 or PID-18

Accepted on discharges only for patient lookup, not for storage into the syngo Workflow SLR database. Either the Medical Record Number, OR the Admission plus a Visit Number, must be valued on the transaction as a whole. syngo Workflow SLR will first try to pull the Patient Admission Number from PID-3. If the Admission Number is not sent by the





Req/ Opt

Refer to: Comments

HIS in PID-3, the field will optionally be pulled from PID-18. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “PN”, then that occurrence of this PID-3 field will be used for the related Admission Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.

Visit Number Visit.pt_visit_no

O PID-3 or PV1-19

syngo Workflow SLR will first try to pull the Patient Visit Number from PID-3. If the Visit Number is not sent by the HIS in PID-3, the field will optionally be pulled from PV1-19. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “VN”, then that occurrence of this PID-3 field will be used for the related Visit Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.



Patient Type Visit_info.pt_type O PV1-18

Discharge Visit_info.pt_dsch_dsp O PV1-36





Req/ Opt

Refer to: Comments

Disposition

Discharge Date/Time

Visit_info.pt_dsch_dtime O PV1-45 If not valued by the HIS, the current transaction date/time will be used.


Pat_usr_flds.type O ZPI-1



O ZPI-3 ZPI-4


Pat_usr_flds.usr_fld_1 Pat_usr_flds.usr_fld_2 Pat_usr_flds.usr_fld_3 Pat_usr_flfds.usr_fld_4






O ZVI-3 ZVI-4

Visit-level User Fields



PD1 ( Patient Additional Demographics) – Primary Care Physician

Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state

O PD1-4 Visit_doctor.dr_type is stored as “PC”. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Master. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.





Req/ Opt

Refer to: Comments

Visit_doctor.dr_zip Visit_doctor.dr_phone

4.3.3 Cancel Discharges Note: Transaction types: A13, A25, A33.


Req/Opt

Refer to: Comments




Patient.pt_med_rec_no

C PID-3 Accepted on discharges only for patient lookup, not for storage into the syngo Workflow SLR database. Either the Medical Record Number, OR the Admission plus a Visit Number, must be valued on the transaction as a whole. The Medical Record Number would always be pulled from this field. The Admission Number will be pulled from this field, if the HIS values it here. Otherwise, the Admission Number will be pulled from PID-18. The Visit Number, if valued, will be pulled from this field, if the HIS values it here. Otherwise, the Visit Number will be pulled from PV1-19. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “MR”, then that occurrence of this PID-3 field will be used for the related Medical Record Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.

Admission/Account Visit.pt_adm_no R PID-3 or Accepted on discharges only for patient lookup, not for storage





Req/Opt

Refer to: Comments

Number PID-18

into the syngo Workflow SLR database. Either the Medical Record Number, OR the Admission plus a Visit Number, must be valued on the transaction as a whole. syngo Workflow SLR will first try to pull the Patient Admission Number from PID-3. If the Admission Number is not sent by the HIS in PID-3, the field will optionally be pulled from PID-18. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “PN”, then that occurrence of this PID-3 field will be used for the related Admission Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.



Patient Location (Nurse Station, Room/Bed)

Visit_info.pt_ns Visit_info.pt_rm_bed

O PV1-3


Visit Number Visit.pt_visit_no

O PID-3 or PV1-19

syngo Workflow SLR will first try to pull the Patient Visit Number from PID-3. If the Visit Number is not sent by the HIS in PID-3, the field will optionally be pulled from PV1-19. The format of the components and the process of valuing the fields is performed the same, regardless of which field this data is found in. If the HL7 Identifier type sent by the HIS in component 5 is valued and converts to a RIS ID type of “VN”, then that





Req/Opt

Refer to: Comments

occurrence of this PID-3 field will be used for the related Visit Number values. The identifier value received from component 1 of this field is concatenated with the check digit value in component 2 of this field, if valued, and then the concatenated value is zero-filled to a 12-digit value used to look up the patient to be discharged, using the patient.pt_med_rec_no field in the database.





O ZPI-3 ZPI-4


Pat_usr_flds.usr_fld_1 Pat_usr_flds.usr_fld_2 Pat_usr_flds.usr_fld_3 Pat_usr_flfds.usr_fld_4






O ZVI-3 ZVI-4




4.3.4 Change Admission Number or Change Medical Record Number Note: Transaction type: A18.





Req/Opt

Refer to:

Comments




Patient.pt_med_rec_no C PID-3 MRG-1

An Old and a New MR# are required for Change MR# transactions. Identifiers are formatted as explained for this field under Admissions and Discharges when they are pulled for these identifier changes.


Visit.pt_adm_no C PID-3 or PID-18

An Old and a New Adm# are required for Change Adm# transactions. Identifiers are formatted as explained for this field under Admissions and Discharges when they are pulled for these identifier changes.

Visit Number Visit.pt_visit_no C PID-3 or PV1-19

Accepted only for patient lookup (if the HIS uses Visit Numbers). Database field not modified. Identifiers are formatted as explained for this field under Admissions and Discharges when they are pulled for these identifier changes.




4.3.5 Swap Patients Note: Transaction type: A17.


Req/Opt

Refer to: Comments




Patient.pt_med_rec_no C PID-3 Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these swap patient transactions.



Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these swap patient transactions.

Patient Class Visit_info.pt_class O PV1-2



O PV1-3

Attending Doctor

Visit_info.atn_dr_no Visit_info.atn_dr_last Visit_info.atn_dr_first Visit_info.atn_dr_middle Visit_info.atn_dr_suffix Visit_info.atn_dr_prefix

O PV1-7 Visit_doctor.dr_type is stored as “AT”. Especially on new admissions, it is advised the HIS send syngo Workflow SLR the attending doctor number and the attending doctor’s last and first names so there is always at least one doctor reference for a patient. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR





Req/Opt

Refer to: Comments

Visit_info.atn_dr_title Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

Doctor Table. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.




Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these swap patient transactions.

4.3.6 Transfers Note: Transaction types: A02, A15.


Req/Opt

Refer to: Comments



Medical Record Patient.pt_med_rec_no C PID-3 Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be





Req/Opt

Refer to: Comments

Number valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these transfer transactions.



Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these transfer transactions.

Patient Class Visit_info.pt_class O PV1-2



O PV1-3

Attending Doctor

Visit_info.atn_dr_no Visit_info.atn_dr_last Visit_info.atn_dr_first Visit_info.atn_dr_middle Visit_info.atn_dr_suffix Visit_info.atn_dr_prefix Visit_info.atn_dr_title Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state

O PV1-7 Visit_doctor.dr_type is stored as “AT”. Especially on new admissions, it is advised the HIS send syngo Workflow SLR the attending doctor number and the attending doctor’s last and first names so there is always at least one doctor reference for a patient. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Table. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.





Req/Opt

Refer to: Comments

Visit_doctor.dr_zip Visit_doctor.dr_phone




Accepted only for patient lookup (if the HIS uses Visit Numbers). Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these transfer transactions.

4.3.7 Orders Field Name syngo Workflow SLR Database

Name Req/Opt

Refer to: Comments



Order Comments Visit_order.ord_comments1 Visit_order.ord_comments2

O NTE-3

Procedure Comments

Visit_activity_info.prc_cmt_1 Visit_activity_info.prc_cmt_2

O NTE-3

Order Placer Number (HIS Order Number, HIS Occurrence Number)

Visit_activity.for_ord_no Visit_activity.frgn_seq_no_val

R OBR-2 ORC-2 ORC-8

Necessary in order for syngo Workflow SLR to send this data back on outbound transactions associated with this order.

Detail Service Code Item.dtl_svc_cd C OBR-4 If profile field IHE_USE_FRGN_ITEM, in profile name INTFC is





Req/Opt

Refer to: Comments

not valued to “Y”: Used for lookup of the item on which to place the order. This data is required if the department+procedure# combination is not used.

Procedure Number Item.proc_no Visit_activity.proc_no

C OBR-4 If profile field IHE_USE_FRGN_ITEM, in profile name INTFC is not valued to “Y”: Used for lookup of the item on which to place the order, in combination with the ordering department. This data is required if there is no detail service code. If the Procedure Number is not received from the HIS, it is determined from the Detail Service Code and loaded into visit_activity.proc_no. If profile field IHE_USE_FRGN_ITEM, in profile name INTFC is valued to “Y”: The HIS’ item code is pulled from OBR-4.1, the Universal Service ID Identifier. The Name of Coding System is pulled from OBR-4.3. syngo Workflow uses these to values to look up the RIS Item (department and procedure number) in the foreign_item table and uses the procedure number from foreign_item.proc_no.

Left/Right Indicator Visit_activity_info.proc_l_r O OBR-15

Ordering Doctor

Visit_order.dr_no Visit_order.dr_last Visit_order.dr_first Visit_order.dr_middle Visit_order.dr_suffix Visit_order.dr_prefix Visit_order.dr_title Visit_doctor.dr_no Visit_doctor.dr_last

R OBR-16 Visit_doctor.dr_type is stored as “OR”. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Table. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.





Req/Opt

Refer to: Comments

Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

IV Indicator Visit_order.iv O OBR-20

LMP Date/Time Visit_order.lmp_dtime O OBR-20

Allergic to Dye Indicator

Pat_info.allergic_dye O OBR-20 Should be sent by the HIS for patient care reasons.

Ordering Department

Dept.dept Item.dept Visit_activity.dept

C OBR-24 If profile field IHE_USE_FRGN_ITEM, in profile name INTFC is not valued to “Y”: Used for lookup of the item on which to place the order, in combination with the procedure number. This data is required if there is no detail service code. If the Ordering Department is not received from the HIS, it is determined from the Detail Service Code and loaded into visit_activity.dept. If profile field IHE_USE_FRGN_ITEM, in profile name INTFC is valued to “Y”: The HIS’ item code is pulled from OBR-4.1, the Universal Service ID Identifier. The Name of Coding System is pulled from OBR-4.3. syngo Workflow uses these to values to look up the RIS Item (department and procedure number) in the foreign_item table and uses the department from foreign_item.dept.

Order Priority Visit_order.priority R OBR-27

Ordered For Visit_activity.ord_for_dtime R OBR-27 If no date/time is received from the HIS, the current transaction





Req/Opt

Refer to: Comments

Date/Time date/time will be used. This is the date/time the order should be performed.

Result copies to Visit_doctor.dr_no Visit_doctor.dr_last Visit_doctor.dr_first Visit_doctor.dr_addr1 Visit_doctor.dr_addr2 Visit_doctor.dr_city Visit_doctor.dr_state Visit_doctor.dr_zip Visit_doctor.dr_phone

O OBR-28 Visit_doctor.dr_type is stored as “RC”. The doctor name as received in the interface will only be used if the doctor number is not loaded in the syngo Workflow SLR Doctor Master. Otherwise, the doctor name is loaded from syngo Workflow SLR based on lookup by the doctor number. An entity doctor number can be used for mapping to a syngo Workflow SLR doctor number if doctors are multi-entity.

Method of Transportation

Visit_order.method_transp O OBR-30

Order Reason Visit_order.reason1 Visit_order.reason2

O OBR-31

Procedure Reason Visit_activity_info.proc_reason O OBR-31

CPT Modifiers Visit_activity_info.cpt_modf1 Visit_activity_info.cpt_modf2 Visit_activity_info.cpt_modf3

O OBR-45 Only the modifiers are pulled from the HIS transaction. The CPT code is loaded from the syngo Workflow SLR Item Table which should match the CPT code in the HIS’s Service Master for the item being ordered.

Order Date/Time Visit_order.ord_dtime O ORC-9

Ordered By Initials Visit_order.ord_by_init O ORC-10 Should always be sent by the HIS on orders so there is some reference if there are any questions on the order.

Ordering Location Visit_order.rqst_loc O ORC-13

Advanced Beneficiary Notice

Visit_order.abn O ORC-20

Medical Record Patient.pt_med_rec_no C PID-3 Accepted only for patient lookup. Database field not modified. Page 45 of 205 Restricted © SIEMENS AG / Siemens

Medical Solutions USA, Inc., 1999, 2013. All rights reserved.

VB10A



Req/Opt

Refer to: Comments

Number Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these order transactions.



Accepted only for patient lookup. Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these order transactions.

Oxygen Indicator Visit_order.o2 O PV1-15

Pregnancy Indicator Visit_order.pregnant O PV1-15


Accepted only for patient lookup (if the HIS uses Visit Numbers). Database field not modified. Either the MR# or the Admission# and any Visit# must be valued. Identifier is formatted as explained for this field under Admissions and Discharges when they are pulled for these order transactions.





O ZPI-3 ZPI-4


Pat_usr_flds.usr_fld_1 Pat_usr_flds.usr_fld_2 Pat_usr_flds.usr_fld_3 Pat_usr_flds.usr_fld_4


Visit-level User Field Visit_usr_flds.type O ZVI-1





Req/Opt

Refer to: Comments

Type



O ZVI-3 ZVI-4




Order-level User Field Type

Order_usr_flds.type O ZOI-1

Order-level User Field Dates

Order_usr_flds.date_1 Order_usr_flds.date_2

O ZOI-3 ZOI-4

Order-level User Fields

Order_usr_flds.usr_fld_1 Order_usr_flds.usr_fld_2 Order_usr_fl

syngo® workflow slr vb10a · 2020. 7. 10. · medseries4 (ms4), unity, or soarian financials. this...

Documents