Вы находитесь на странице: 1из 24

CHARGING INTERFACE

Mariam Chaaban on 15 January 2019

1 OVERVIEW

1.1 Project Description


Describe the high-level scope and purpose of this project; example HCLL Integration comprises of sending patient
administration information (ADTs) from Epic to HCLL; blood product requests from Epic to HCLL; and receive
incoming blood product results status, etc.

Charging Integration project is an interface between Epic and AS400 (AUBMC Charging System).Epic sends charges
to AS400 and receives Clearance from AS400.

1.2 Project Stakeholders


List the groups, roles & names of the various stakeholders (operational, AUBHealth, Core IT, etc.) involved in the
project; such as Operational > Lab Administrator > Jane Doe

This project mainly includes:

 AUBHealth applications Team (Raed Rafeh, Hisham Bawady, Ahmad Kaaki) Commented [RA1]: Include specific names for
 AS400 Team (Mr. Karam Rizk, Zahraa Azwar, Wissam Shehab) anyeone to followup with for any further details
 Application Finance Team (Farah KHATIB MISKAWI, Dima Issa, Yolla Kanaan, Helene Demian) Commented [AA2R1]:
 All Operational owners that are charging on Epic (Procedure, LOS, etc…).
Commented [AA3R1]:
Commented [AA4R1]:

1.3 High-Level Requirements


Describe the high level requirements for the project. For example:

The new system must include the following:

 Ability to interface with the existing data warehouse application


 Ability to incorporate automated routing and notifications based on business rules

1
2 TECHNICAL

2.1 Architecture
Diagram highlighting the different systems integration or interaction; being systems, databases, servers, etc.

Commented [RA5]: Add the callensemblewebservice


piece into the diagram between ensemble & AS400
Also add the connection to mcnasfiles
Commented [AA6R5]:

MCNASFILES
HCLL Pyxis

AS400 DB

Epic Bridges Ensemble AS400

\\poseidon\enswebservicetst$\HEALTHCDEV\CallEnsembleWebservice.exe

User Hyperspace PA Workstation Cashier Workstation

2.2 Integration Business Rules


Refer to the applicable section of the template depending on the nature of the project; of whether a
development .NET or integration through Ensemble or Bridges

2.2.1 Quick Reference

List the IPs, Ports, interface names (AIPs) utilized and referred to in the subsequent sections .

 AS400 OUTGOING ANCILLARY ORDERS [400]: sends to healthc port 60501 which sends AS400
orders to AS400 DBs (Outpord for outpatient and inpord for inpatient)

2
 OUTGOING FINANCIAL TRANSACTIONS [334750] sends to healthc port 60512 which sends AS400
charges to AS400 DBs (Outpord for outpatient and inpord for inpatient)
 OUTGOING FINANCIAL TRANSACTIONS - REQUISITION ENABLED [334752] sends to healthc port
60511 which sends AS400 charges to AS400 DBs (Outpord for outpatient and inpord for
inpatient)
 INCOMING ORDERS CLEARANCE FROM AS400 [334317] Receives the order Financial Clearance from
AS400 on healthc port 60525
 OUTGOING APPOINTMENT SCHEDULING [334500] sends to healthc port 60502 which sends inpatient
clearance requests to AS400 for certain types of procedures (example: DSA, PET CT)
 OUTGOING SURGICAL CASE SCHEDULING [334502] sends to healthc port 60602 which sends OR
clearance requests to AS400
 INCOMING SURGICAL CASE TRACKING [334513] Receives clearance for inpatient OR requests from
AS400 on healthc port 60578

2.2.2 Ensemble Detailed Block Diagram

Detailed Block diagram showing the communication between the different ensemble components such as services,
processes, operations. Include a screen shot from ensemble portal for processes

Outgoing Charging Interfaces

Services Process Operations


SRV_Epic_TCP_Charge PRC_GetDFTRoute Charges OPR_AS400_ChargingLookups
SRV_Epic_TCP_Charge_Req PRC_GetDFT_InDB2Charges OPR_AS400_DB2_InsertInpatientCharges
PRC_GetDFT_InpatientCharge OPR_AS400_Cache_ManageData
PRC_DFT_DB2_Charges OPR_AS400_DB2_GenerateRefNo
OPR_AS400_DB2_InsertDB2Charges
OPR_AS400_RetrieveData

3
Outgoing Orders Interface

Services Process Operations


SRV_EPIC_TCP_ORM PRC_EPIC_ORM_Router OPR_AS400_DB2_InsertInpatientOrder
PRC_EPIC_ORM_Router_Charging OPR_AS400_DB2_InsertInpatientCharges
PRC_GetORM_InDB2Charges OPR_AS400_ChargingLookups
PRC_InpatientOrders_AddInpatientO OPR_AS400_Cache_ManageData
rders
PRC_InpatientOrders_Charging OPR_AS400_DB2_GenerateRefNo
PRC_AddDB2Charges_OutDB2Char OPR_AS400_DB2_InsertDB2Charges
ges
PRC_Epic_InpatientProcedureCleara OPR_AS400_RetrieveData
nceCancelation_ORM
OPR_AS400_DB2_ProcedureClearanceRequest

Incoming Clearance Interface

Services Process Operations


PKGAS400. PRC_AS400_Handle_OrderFinanci OPR_AS400_Cache_ManageData
CSRVAS400WebServiceCharging alClearance

OPR_AS400_DB2_GenerateRefNo
OPR_AS400_RetrieveData

4
OPR_FC_TCP_ORM

2.2.3 Bridges Business Rules

Highlight specific configuration at profile variables done specific for this integration. Name the interface name,
associated error workqueues if applicable

5
2.3 Development Business Rules
Refer to the applicable section of the template depending on the nature of the project; of whether a
development .NET or integration through Ensemble or Bridges

Here we will talk about all process, rules and special cases done at the interface engine:

2.3.1 Charging Interface Commented [RA7]: Switch the sections with the
1. Epic sends a Charging DFT message from 2 interfaces ensmeble components details.
a. outgoing Financial Transactions Interface (AIP: 334750) Commented [AA8R7]:
b. outgoing Financial Transactions Interface-Requisition Enabled (AIP: 334752)
2. Ensemble Receives the Charging message via 2 services (SRV_Epic_TCP_Charge and
SRV_Epic_TCP_Charge_Req) that sent the message to the same process
3. PRC_GetDFTRoute Charges; uses the Transform DTLDFTRoutingCharges to evaluate the patient class of
the message if outpatient or inpatient then sends the message to PRC_GetDFT_InDB2Charges process.
4. PRC_GetDFT_InDB2Charges process do the below:
a. If the charges are not free of charges (Charge code = 99999, or contains a modifier of 100% discount)
b. Else then
i. checks the patient class of the message
ii. Transform the message from DFT to InDB2Charges using the DTLDFTInDB2Charges Data
Transformation.
iii. Sends the new message (InDB2Charges) to the specific process:
1. Inpatient : PRC_GetDFT_InpatientCharge
a. Vial Medication part:
i. If Charge is a vial Medication
1. Get linked charges from the DR Code received in the
message using the query:
select DRUGID,QTY from QS36F.mixture m inner join
QS36F.drugvials v on m.MIXID = v.MIXID where NDCCode =
@DRCode

If charge status is not equal to Cancelled

a. add all related charges to inpord table with


SRBilled = 0

If charge status is equal to Cancelled

b. Get Inpord Record Status from SRVBilled Flag


c. If status = 1 => sent to bill
i. Add a negative charging record to
inpord (refund)
d. If status = 0 => Charge is not yet sent to the bill
i. Delete charges from inpord
ii. Add record to Archive
ii. If Charge is not a vial Medication
1. Get Related Order ID from the message, if exists:
a. If a pending order related to the charge exists in
inpord :
i.
b.
2. Outpatient: PRC_DFT_DB2_Charges
If Charge status not equal Cancelled
a. Set drop charge = Yes

6
a. If number of consultation > 0 then exit drop
charge = No
b. Else set drop charge = Yes
iv. If drop charge = Yes

b. If Charge is a vial Medication


i. Get linked charges from the DR Code received in the message
using the query:
select DRUGID,QTY from QS36F.mixture m inner join QS36F.drugvials v
on m.MIXID = v.MIXID where NDCCode = @DRCode
c. Loop the charges in the message and do:
i. If Pathology Charge
1. Get Pathology procedure code from cache
TempOutCharges table to add the charge as a normal
order
ii. If ED Consultation Charge (Unit = EUD and CPT Code = 99281)
1. Get Number of consultations dropped for this patient in
the ED
iii. If drop charge = Yes
1. Generate Reference No using the logic below:

Same encounter, group under the following order types (Refer to TBL_OrderGroupig):
 Lab
 Radiology
o IR alone
 Deposit alone
 Anesthesia alone
o Non IR alone
 Physiotherapy (by unit; Physical Therapy , Occupational Therapy )-> By CSN
 Endoscopy -> By CSN
 Other: All the following together:
o Pathology
o Supplies
o Consultation
o Medication
o …..

2. Add a record to outpord.

If Charge status is equal to Cancelled:


a. Get Record information from Cache temp table (Referno, linenum)
b. Get Clearance status from AS400
c. Update cache record status to Cancelled
d. If AS400 charge status = cleared
a. Add a negative charge to AS400 (Refund)
e. Else
a. Delete the charge record from AS400
b. Add this record to AS400 archive (outpordLog)

7
2.3.2 Ordering Interface
Overview

Epic sends a Charging ORM message from AS400 Outgoing Ancillary Orders (AIP: 400)

1. Ensemble Receives the Orders message via the service SRV_EPIC_TCP_ORM and sends the message to the
process PRC_EPIC_ORM_Router, PRC_EPIC_ORM_Router_Charging.;
1. These processes evaluates the order type: admission, Transfers and real orders and send it to the
process
2. These processes Transform ORD to ORM Message using the DTLDFTRoutingCharges, to derive the
right class to route the Order charges to (Inpatient vs Emergency or Outpatient) in the next process
2. PRCGetORMInDB2ChargesRoutingRule: This process evaluates the patient class in the message, Transform the message
to the class InDB2Charges using the data transformation DTLORMInDB2Charges and sends it to right process based on the
workflow:
1. Patient Class = Inpatient and Order Type in (PFT, Neurology, Sleep Center, Audiology, Imaging but not EKG OR
procedure is mapped to drop charges on order entry (~INPATIENT_CHARGE_ORDER_ENTRY^Y))
i. Drop charges on order Entry via the process PRC_InpatientOrders_Charging
2. Patient Class is Outpatient/Emergency or patient class not specified in the message
i. Here the charges are dropped on order entry to the outpatient settings via the process
PRC_AddDB2Charges_OutDB2Charges
3. Patient class = Inpatient and order Type not stated in the point #1, then Add a pending order via the process
PRC_InpatientOrders_AddInpatientOrders
4. Patient class = Inpatient and order category is IR or CT and message type is cancellation, cancel the inpatient
procedure clearance request through the PRC_Epic_InpatientProcedureClearanceCancelation_ORM

Process Business Rules

PRC_InpatientOrders_Charging: Inpatient order charging

1. If the Order is an Interventional Radiology, do nothing.


For IR, we do not add any order to AS400 to lock the discharge since the order message has not a link to any charging
message (IR Charging is done through charge Capture)
2. If the Order is not an Interventional Radiology
a. If Charging an Orders:
i. Loop in all linked charges to the order (CPT, CDM and other linked charges such as questions) and add
them to the inpord table
b. If Cancelling an order:
i. Get Order Status from Inpord billed or not
1. If order is billed, add negative charges to inpord (refund charges)
2. If Order is not billed, then delete the order charges from inpord and add the order charges to
archive
a. Note: when deleting the order and order does not exist in inpord, and order source unit
is ED or L&D do cancellation from outpord

PRC_InpatientOrders_AddInpatientOrders: Inpatient order

1. If Charging an Orders: Add a pending order to inpord,


2. If Cancelling an order:if the order is not charged yet, delete the pending order from inpord
a. Note: when deleting the order and order does not exist in inpord, and order source unit is ED or L&D do
cancellation from outpord

PRC_AddDB2Charges_OutDB2Charges: Outpatient order charging

1. Non Interventional Radiology Order Charging


a. Order : Loop in all linked charges to the order (CPT, CDM and other linked charges such as questions) and

8
i. Check Contrast rule: do not charge if:
1. Same Patient
2. Same encounter
3. Same Charge Code
4. Status not Cancelled
5. Within 3 hours
ii. Check pathology :
1. If pathology, then don’t add the charge now, add it when get the charge message
iii. Generate Refno by adding a record in temp cache table (Tempoutcharges)
iv. add the charges to the outpord table
b. Cancellation:
i. Get Record information from Cache temp table (Referno, linenum)
ii. Get Clearance status from AS400
iii. Update cache record status to Cancelled
1. If AS400 charge status = cleared
a. Add a negative charge to AS400 (Refund)
2. Else
a. Delete the charge record from AS400
b. Add this record to AS400 archive (outpordLog)
2. Interventional Radiology Order Charging

Identify an Interventional Radiology order, whereby we need to identify the deposit charge code: 00846

a. Order :
i. Generate a refno for the deposit and add the record to outpord
ii. Loop in all anesthesia charges, Generate a refno for the chargesand add the records to outpord

b. Cancellation
i. Get Record information from Cache temp table (Referno, linenum)
ii. Get Clearance status from AS400
iii. Delete or Refund records in AS400 and update cache temp table status to cancelled

PRC_Epic_InpatientProcedureClearanceCancelation_ORM: Inpatient procedure clearance cancellation

Call operation OPR_AS400_DB2_ProcedureClearanceRequest with TrxType flag = ‘C’ to cancel the clearance request in
AS400.

2.3.3 Outpatient Orders Clearance in AS400


Epic receives outpatient orders clearance information from AS400 through the Incoming Orders Clearance from
AS400 [334317].

Ensemble receives the clearance information via the service CSRVAS400WebServiceCharging. If AS400 calls
\\poseidon\enswebservicetst$\HEALTHCDEV\CallEnsembleWebservice.exe with first parameter = "21", the
ProcessOutpordFC method will be called in the CSRVAS400WebServiceCharging service which will in turn send the
message to the PRC_AS400_Handle_OrderFinancialClearance process.

Process Business Rules

PRC_AS400_Handle_OrderFinancialClearance

 This process first checks if the patient id is available in the AS400 call. If so, call
OPR_AS400_Cache_ManageData operation to get the record related to this call from the
PKGAS400.TempOutCharges cache table:

9
1. If record doesn’t exist or cancelled or AS400 call doesn’t contain a charge code, then only call
OPR_AS400_DB2_DeleteLog operation to delete the related record from outpordlog.
2. If record exists, update receipt information in cache table and then call the
OPR_AS400_Cache_ManageData operation to check if all charges related to this order are
cleared:
a. If not all are cleared, then only call OPR_AS400_DB2_DeleteLog operation to delete the
related record from outpordlog.
b. If all charges are cleared, the OPR_FC_TCP_ORM operation is called to send the ORM
message to clear the order in epic.
3. Check if order is related to ED
a. If not ED, do nothing
b. If ED and patient has no bed then check if disposition = ‘L’:
 If true, call process PRC_AS400_Handle_MsgAdmLog to clear the patient’s
discharge clearance value.
 If false, call process PRC_AS400_EDDischargeClearance to evaluate and
update the patient’s discharge clearance.

2.3.4 ED Workflow logic after charging a DFT or an ORM


1. Discharge clearance update after order or charging:
a. Get ED Visit record from AS400, by using the query below; this query is evaluating is the patient has an
open inpatient encounter
select
from qs36f.patientd as PatientD left join
qs36f.masterin as Master on PatientD.caseno = Master.caseno

where ADMLOCAT in ('EU','EDT','EDX')

b. If patient is still In the ED and not yet admitted, and discharge disposition is filled;
i. Check Pending AR Balance AUH.CHKAR296
ii. Check Pending outpord charges
iii. If all the above are cleared then send discharge clearance to Epic
iv. Elsewise, sent discharge not cleared to Epic
2. ED patients with 070 guarantor:
a. If patient is in the ED, he is admitted on 070 guarantor and once we charge an order on this patient an
order Financial Clearance will be automatic sent to epic without clearing this order on AS400.

2.3.5 Pool Codes Logic

Due to the fact that charges are dropped at order entry in Epic and that the performing provider is not known at that
point of time, we adopted the concept of pool codes similar to group practices. However, some specialties like the
Neurology & Vascular do NOT follow the group practice. Accordingly, it is required to adjust the Pool Code to the
correct individual doctors upon performing the procedure.

Two scenarios apply for ordering:

10
Outpatient:

 A vascular or Neurology EAP is linked to a Pool Code (Neurology: 05301, 05302 and Vascular = 05098)
 Once the ordering Provider adds this kind of orders; we will write the charge codes and CPT Codes to
QS36F.outpord; the CPT Codes routed to the designated Pool code (linked to the ordered EAP).
 The cashier clears the order.

Inpatient

 A vascular or Neurology EAP is linked to a Pool Code (Neurology: 05301, 05302 and Vascular = 05098)
 Once the ordering Provider adds this kind of orders; we will write the charge codes and CPT Codes to
QS36F.inpord; the CPT Codes routed to the designated Pool code (linked to the ordered EAP), in addition an
identifier “G” is flagged in SRVBilled column to keep the order pending.
 The billing program postpones all these flagged records from processing until the order is performed and marked
with the performing provider.

Once the procedure is performed, technicians the order is mark the order with the performing provider in the Epic
items ORD-52051 for Neurology and ORD- 52225 for vascular following specific workflows.

A daily extract done by the cogito team that retrieves all the performed procedures and write them to a text file in the
format:

Epic Order ID|Epic Procedure Name|Epic Procedure Name|EAP Pool Code|Performing Provider Name|Performing Provider
Code|Patient MRN|Patient Name|Epic Procedure Code|Performing Date|Patient Class|Epic Order parent ID|Epic Order Child ID

The extract generated every day at 4:00 am, and located on the below path:

\\mcnasfiles.win2k.aub.edu.lb\cogito_extracts$\ensemble\poolcodes\PRD

The interface evaluate the extract and do the following: [SRV_TextExtract_FileStream_PerformPhysician]

If the patient Class = Outpatient then

 Get the receipt No from Cache based on one of the Epic Order IDs (Main ID, Parent ID or Child ID)
 If all data required exist then
a. Write a record in AS400 in QS36F.DOCGRPADJ
 Else (one of the following columns is missing – Performing Doctor or Receipt No)
a. Write a record in Cache table on Ensemble named “PKGAS400.TempDocGrpAdjError”

11
If the patient Class = Inpatient then

 The interface engine should replaces the group charge code with the private doctor's charge code and the status
SRVBilled "G" with "0" in AS400 in QS36F.INPORD table
 The AS400 billing program ignores these records flagged as SRVBILLED = “G“ until they are updated with the
correct charge code and converted into “0”; then will sends this record to the patient’s Bill; or Until the patient is
discharged.
 If any error occurs, a record will written in Cache table on Ensemble named “PKGAS400.TempDocGrpAdjError”
and the comment updated with the error description.

Issues

Two new scenarios discovered after the above implementation done:

ED/L&D to inpatient

If the order is created when the patient is in ED/L&D then patient is admitted as inpatient; the patient class in the
extract is retrieved from the final state of the patient (in this case, it is inpatient)

It was resolved as such: once the patient class is received as inpatient in the extract, once we update the record in
inpord but no rows are updated, we need to check if a record is added to cache temporary table with a receipt
number, in this case, we will follow the outpatient workflow.

Procedures Performed after patient discharge

The order created when the patient is inpatient; then patient is discharged before the performing physician marked
the order as completed.

In this case, the AS400 team will move all the in QS36F.DOCGRPADJ with the doctor code empty

Once the extract is generated and the patient is inpatient, the interface will search for this record in
QS36F.DOCGRPADJ and update the Doctor code

The billing system will route the charges to the doctor code specifies

2.3.6 OR/Cardiac Cath Clearance request and Discharge Locking Logic


Epic sends surgical case scheduling SIU message from Outgoing Surgical Case Scheduling [334502] when changes
on the surgical log/case occur.

Ensemble receives the scheduling message via the service SRV_EPIC_TCP_SurgicalSIU and sends the message to
the process PRC_Epic_SurgicalSIU_Router then PRC_Epic_OREvents.

Process Business Rules

PRC_Epic_OREvents

1. If log event = ‘in room’, call OPR_AS400_DB2_CheckOROrder to check if a previous record was inserted into
inpord for a pending surgery. If not, call process PRC_InpatientOrders_AddInpatientOrders to add a pending
surgery record in inpord to lock patient discharge.

2. If log event = ‘Posted’, call OPR_AS400_DB2_UpdateOROrder to update SRVBILLED to ‘1’ in inpord in order to
unlock patient discharge in AS400. If this is a surgery case, send SIU message to

12
OPR_NSPMaterials_TCP_SIU to be received and handled in the NSPMaterials namespace (refer to
NSPMaterials documentation)

3. If case created or scheduled


a. If patient class is outpatient and admission form filled, transform scheduling message into an
admission order message and call PRC_EPIC_ORM_Router to create an ebooking in AS400.
b. If patient class is inpatient and room request field filled, call
OPR_AS400_DB2_ProcedureClearanceRequest to send surgery clearance request to AS400.
c. If patient class is emergency, do not send anything to AS400 since an admission order is expected.

4. If case is cancelled or voided


a. If patient class is outpatient and admission form filled, call
OPR_AS400_DB2_CancelAdmSurgReq to cancel the ebooking created in AS400.
b. If patient class is inpatient and room request field filled, call
OPR_AS400_DB2_ProcedureClearanceRequest to cancel surgery clearance request sent
previously to AS400.
c. If patient class is emergency, do not send a cancellation to AS400.

2.3.7 Inpatient OR/Cardiac Cath Clearance in AS400


Epic receives OR/Cardiac Cath clearance information from AS400 through the Incoming Surgical Case Tracking
[334513].

Ensemble receives the clearance information via the service CSRVAS400WebServiceCharging. If AS400 calls
\\poseidon\enswebservicetst$\HEALTHCDEV\CallEnsembleWebservice.exe with first parameter = "25", the
ProcessInpatientORClearance method will be called in the CSRVAS400WebServiceCharging service which will in turn
send the message to the PRC_AS400_ORCLearance process.

Process Business Rules

PRC_AS400_ORCLearance

 This process first transforms the data received from the AS400 call to an SIU message. Patient
demographics are then populated in this message by calling the PRC_Nsp_GetPatientInfo process. After
that, the OPR_NSPMaterials_TCP_SIU operation is called to send the SIU message to clear/unclear the
surgery/Cath case in epic.

2.3.8 Inpatient Orders Clearance Request


Epic sends appointment scheduling SIU messages from Outgoing Appointment Scheduling [334500]. Applies for IR
and PET CT.

 Ensemble receives the scheduling message via the service SRV_EPIC_TCP_SIU and sends the message to the
process PRC_EPIC_SIU_Router then PRC_Epic_InpatientProcedureClearance_SIU.

Process Business Rules

13
PRC_Epic_InpatientProcedureClearance_SIU

 SIUs received from Epic include multiple orders that may or may not require clearance. Clearance logic is as
follows:
 Check in the scheduling message if patient class = ‘inpatient’ and event = ‘scheduling’ and procedure category
(EAP 200) of any of the contained orders = ‘11’ (CT) or ‘18’ (IR), then:
1. Check for each individual order if needs clearance. If yes, call operation
OPR_AS400_Cache_ManageData (GetCountClearedIRDeposit method) to check if a cleared deposit
already exists for this order (as in scenarios where by the ED Patient pays a deposit as out; then he/she
gets admitted). If the order has no cleared deposit yet, call operation OPR_AS400_ChargingLookups
(GetProcedureClearanceCodes method) to get the charge codes to be sent for clearance as follows:
i. If procedure category is IR, do not get any charge code (since these will be added in the
inpatient financial clearance web app)
ii. If procedure is PET CT get the codes from inpord using the following query:
select 'P',substr(xmlserialize( xmlagg( xmltext( concat(cptcode||','||lpad(cast(qty as
integer),3,0),',' ) ) ) as
varchar( 1024 ) ),0,length(xmlserialize( xmlagg( xmltext( concat(cptcode||','||lpad(cast(qty
as integer),3,0),',' ) ) ) as varchar( 1024 ) ))) chgitems
from QS36F.inpord
where caseno = '"_pRequest.Caseno_"' and referno = '"_pRequest.OrderID_"' and
trim(cptcode) != ''
union
select 'H',substr(xmlserialize( xmlagg( xmltext( concat(chgcode||','||lpad(cast(qty as
integer),3,0),',' ) ) ) as
varchar( 1024 ) ),0,length(xmlserialize( xmlagg( xmltext( concat(chgcode||','||lpad(cast(qty
as integer),3,0),',' ) ) ) as varchar( 1024 ) ))) chgitems "
from QS36F.inpord
where caseno = '"_pRequest.Caseno_"' and referno = '"_pRequest.OrderID_"' and
trim(cptcode) = '' and trim(chgcode) != ''

Then call operation OPR_AS400_DB2_ProcedureClearanceRequest to send the clearance request to


AS400.

2.3.9 Inpatient Orders Clearance in AS400


Epic receives inpatient orders clearance information from AS400 through the Incoming Orders Clearance from AS400
[334317].

Ensemble receives the clearance information via the service CSRVAS400WebServiceCharging. If AS400 calls
\\poseidon\enswebservicetst$\HEALTHCDEV\CallEnsembleWebservice.exe with first parameter = "26", the
ProcessInpatientProcedureClearance method will be called in the CSRVAS400WebServiceCharging service which will
in turn send the message to the PRC_AS400_InpatientProcedureClearance process.

Process Business Rules

PRC_AS400_InpatientProcedureClearance

 This process first transforms the data received from the AS400 call to an ORM message. Patient
demographics are then populated in this message by calling the PRC_Nsp_GetPatientInfo process. After
that, the OPR_FC_TCP_ORM operation is called to send the ORM message to clear/unclear the order in
epic.

14
2.3.10 Source Code Information

Highlight of feature and location of source code

Bridges Custom Code:

AIP 334500
Literal code: f line=1:1:%AIM("Orders",0) s
Proc=$$zgetnp^elibEAnLIB11("ORD",%AIM("Orders",line),40,1,99999),%AIM("AIS","ID")-
=%AIM("AIS","ID")_$$geti^elibEAnLIB1("EAP",Proc,100,1,99999)_%AIHead("cs")_$$geti-
^elibEAnLIB1("EAP",Proc,200,1,99999)_%AIHead("rs")
Found in: APPT_PROC_PP
What this does: This code sets subnodes in %AIM("AIS") in order to send the EAP
100/200 from all attached orders in AIS-3 in the outgoing SIU message.
Why it's needed: This code is needed so that for inpatient order clearance purposes, we can loop through
all orders attached to the scheduling message and determine which ones need clearance in AS400 based
on their procedure category (EAP 200)
SLG 3675411

AIPs 400, 334750, 334752


Literal code:
$$getMessage^S2LPP3(721329,,,$p(%AIM("idList"),"&"),$p(%AIM("idList"),"&",3))
Found in: RCV_APP_FUNC
What this does: Code that returns the error message of a rule (CER record),
typically used in Cadence LPPs. AUB uses it with order messages related to
oncology encounters to flag messages as belonging to a 'previous oncology visit'
in MSH-5. The rule looks to see if there was a previous oncology visit on the
same day as the current oncology encounter and returns the visit type from the
previous visit if a previous oncology encounter exists.
Why it's needed: This is needed for grouping charges on the correct bill in AS400
(billing system) downstream. All oncology visits that occur on the same day are
billed together and thus subsequent oncology visits need to be flagged to
indicate that a previous oncology visit has already occurred.
SLG 3838430

AIP 334804
Literal code: k %AIM("NTE") s
caseID=$s(%AIM("INI")="ORL":$$geti^elibEAnLIB1("ORL",%AIM("ID"),920,1,99999),1:%A-
IM("ID")),%AIM("NTE","line")=1,%AIM("NTE")=$$znam^elibEAnLIB2("EDP",$$getidin^eli-
bEALIB1($$geti^elibEAnLIB1("EAP",$$geti^elibEAnLIB1("ORD",$$zgetnp^elibEAnLIB11("-
ORC",caseID,7500,1),40,1),200,1,99999),"EDP")) d
call^AISend(%AILT(%AIPid,"TxArr",%AIMMsg,"NTE",1),context,event)
Found in: AFTER_MSG_CREATE
What this does: Code gets procedure category (I EAP 200) from the order in the

15
first line of I ORC 7500 attached to ORC( or the ORC attached to ORL for
log-based messages) and then sends that procedure category as an NTE at the end
of the message.
Why it's needed: This code is needed specifically for Cardiac Cath / Cardiac EP
cases so that charges can be grouped on 'inpatient' bill correctly downstream in
AS400 (Reg/Billing system)
SLG 3938613

2.4 Ensemble Component Description


Describe the purpose of each ensemble component (service, process, operation) utilized and include the names of
databases or destination system it interact with; or receives from. Example:

2.4.1.1 Services
 SRV_Epic_TCP_Charge: TCP/IP service that receives DFT message from Epic’s outgoing Financial
Transactions Interface (AIP: 334750)
 SRV_Cache_ForSync: Database Inbound Adapter service that reads PKGAS400.TempOutCharges cache table
records to synchronize them with AS400 table.
 SRV_Epic_TCP_Charge_Req: TCP/IP service that receives DFT message from Epic’s outgoing Financial
Transactions Interface-Requisition Enabled (AIP: 334752)
 SRV_EPIC_TCP_ORM: TCP/IP service that receives ORM message from Epic’s AS400 outgoing Orders
Interface (AIP: 400)
 SRV_EPIC_TCP_SIU: TCP/IP service that receives SIU messages (appointment scheduling) from Epic’s
outgoing appointment scheduling interface (AIP: 334500)
 PKGAS400.CSRVAS400WebServiceCharging: This service is a web service that is called from AS400 through
\\poseidon\enswebservicetst$\HEALTHCDEV\CallEnsembleWebservice.exe to perform an action in Epic
(example: send order clearance information to Epic)
 SRV_TextExtract_FileStream_PerformPhysician: This service is a file listener to
\\mcnasfiles.win2k.aub.edu.lb\cogito_extracts$\ensemble\poolcodes\PRD that reads from a file to update AS400
poolcodes (Outpatient, inpatient and ED) to the correct performing provider.
 SRV_EPIC_TCP_SurgicalSIU: TCP/IP service that receives SIU messages (OR scheduling) from Epic’s
outgoing surgical case scheduling interface (AIP: 334502)

2.4.1.2 Processes:
 PRC_AddDB2Charges_OutDB2Charges: a business process that evaluates the outpatient order message,
generates the charges’ referno, and sends this information to an operation
(OPR_AS400_DB2_InsertDB2Charges) that adds the charge in AS400.
 PRC_AS400_Doc_Group_Adjustment: a business process that evaluates completed pool code orders
information, process them according to the patient class, and route them to the respective operation
(OPR_AS400_DoctorGroupAdjustment) that sends this information to AS400.
 PRC_AS400_ED_RegistrationClearance: a business process that evaluates charge clearance information
coming from AS400, checks if those charge are coming from ED and if the charges are ED registration Fees

16
(CDM 01000, CPT 05100, CDM 01007, CDM 01002) and are all cleared then send a full registration message
(ADT A08) to Epic through the OPR_Epic_TCP_ADT operation.
 PRC_AS400_EDDischargeClearance: a business process that is called for all ED patients when adding order
charge from Epic or sending Clearance from AS400. It evaluates if the patient has any remaining charges not
cleared or if the patient has any remaining balance from past encounters and accordingly it either sends a
discharge clearance or not cleared for the ED encounter to Epic through the OPR_Epic_TCP_ADT operation.
 PRC_AS400_EDDischargeOrder: a business process that is called when we set a disposition for an ED patient.
It will update the disposition value in AS400 for the two tables (PatientD and EUPPat) then it will call the process
PRC_AS400_EDDischargeClearance.
 PRC_AS400_EDDuringPatientStay: a business process that calls PRC_AS400_EDDischargeOrder, and
based on the response (which is the number of non-cleared charges in outpord), it will set the encounter
clearance flag in AS400, update encounter clearance in Epic, and send discharge clearance status to epic if a
disposition is set.
 PRC_AS400_Handle_OrderFinancialClearance: a business process that evaluates charge clearance
information coming from AS400, checks if all the charges associated with the order are cleared, and route them
to the respective operation that sends Epic an order clearance notification. Also for ED patients, it evaluates if
all charges are cleared in order to send Epic a discharge clearance notification through the
OPR_Epic_TCP_ADT operation.
 PRC_AS400_Handle_UnclearOrder: a business process that processes the charge unclear information coming
from AS400, to be sent to epic in order to unclear the respective order through the OPR_FC_TCP_ORM
operation.
 PRC_AS400_InpatientProcedureClearance: a business process that processes the inpatient order clearance
information coming from AS400, to be sent to epic in order to clear/unclear the respective order through the
OPR_FC_TCP_ORM operation.
 PRC_AS400_ORCLearance: a business process that processes the inpatient OR clearance information coming
from AS400, to be sent to epic in order to clear/unclear the respective surgery through the
OPR_NSPMaterials_TCP_SIU operations.
 PRC_AS400_PayAcc_ForceDischarge: a business process that is called for ED patients when the event Force
discharge or Payment on account are done on AS400; and based on it a discharge clearance message is sent
to Epic through the OPR_Epic_TCP_ADT operation.
 PRC_Cache_AS400Sync: This is a synching process that sends the missing records from cache temp table to
AS400 table (outEpicMap) through the OPR_Cache_AS400_WriteData operation.
 PRC_DFT_DB2_Charges: a business process that processes outpatient charge (DFT) messages. If the charge
corresponds to a medication vial charge, it will retrieve the associated charge codes from AS400. Otherwise it
will use the message charge codes. After that, depending on whether the message is a new charge or
cancellation and if the charge is already cleared or not, operation OPR_AS400_DB2_InsertDB2Charges will
either add or delete a record in outpord after generating referno in cache table.
 PRC_Epic_InpatientProcedureClearance_SIU: a business process that evaluates the data received in the
appointment-scheduling message. If the scheduled order is for an inpatient and needs clearance, it would route
this information to an operation (OPR_AS400_DB2_ProcedureClearanceRequest) that sends a clearance
request to AS400.
 PRC_Epic_InpatientProcedureClearanceCancelation_ORM: a business process that evaluates the data
received in the order cancellation message. If the cancelled order is related to an inpatient and needed
clearance, it would route this information to an operation that sends a clearance request cancellation to AS400
through the OPR_AS400_DB2_ProcedureClearanceRequest operation.
 PRC_Epic_OREvents: a business process that evaluates the data received in the surgical case scheduling
message. According to values such as patient class and surgery status, it will either send an OR clearance

17
request, delete the clearance request, send an inpatient pending order to stop discharge, update this pending
order to allow discharge, or do nothing.
 PRC_EPIC_ORM_Router: an HL7 router that routes the message to another process depending on whether it’s
an admission order (PRC_EPIC_ORM_Router_ADT) or a charging order (PRC_EPIC_ORM_Router_Charging).
 PRC_EPIC_ORM_Router_Charging: an HL7 router that sets the correct patient class in the message (example:
if visit type is infusion it would set the class to inpatient) before routing it to the PRC_GetORM_InDB2Charges
process.
 PRC_Epic_SendCArm_SIU: an HL7 router that sends the OR scheduling information involving C-Arm usage
(after transforming it from a scheduling message to an order message) to an operation
(OPR_NSPAgfa_TCP_ORM) that sends it to Agfa.
 PRC_GetDFT_InDB2Charges process: an HL7 router that evaluates the DFT message coming from epic and
then either do nothing with it (in case it’s a discount) or route it to PRC_GetDFT_InpatientCharge in case the
patient class was inpatient or to PRC_DFT_DB2_Charges if patient class was outpatient.
 PRC_GetDFT_InpatientCharge: a business process that processes inpatient charge (DFT) messages. If the
charge corresponds to a vial medication it would get the related charge codes and route them to the AS400
charge insert operation. Otherwise, it would send the charges listed in the message. If the charge message is a
refund, it would either call the AS400 operation (OPR_AS400_DB2_InsertInpatientCharges) to delete the
corresponding records from inpord or insert a refund entry depending on whether the charge was billed or not.

 PRC_GetDFTRoute Charges: an HL7 router that sets the correct patient class in the message (example: if visit
type is infusion it would set the class to inpatient) before routing it to the PRC_GetDFT_InDB2Charges process.

 PRC_GetORM_InDB2Charges: an HL7 router that routes the order message to the respective operation
depending on certain criteria such as the patient class, order control, and order type.
 PRC_InpatientOrders_AddInpatientOrders: a business process that deals with registering/deletion of inpatient
orders. If a cancellation is for an ED order which was initially added when the patient class was outpatient, it
calls an operation that deletes it from outpord. If the order message is a cancellation, it would either call the
AS400 operation to delete the corresponding records from inpord or insert a refund entry depending on whether
the charge was billed or not.
 PRC_InpatientOrders_Charging: a business process that handles inpatient order charges for orders that are
charged on entry (example: imaging). Interventional radiology orders are excluded since these are charged
using charge capture.
 PRC_Epic_SurgicalSIU_Router: an HL7 router that receives HL7 messages from the
SRV_EPIC_TCP_SurgicalSIU service and sends them to OPR_NSPORPatientTrack_TCP_SIU,
PRC_Epic_SendCArm_SIU, and PRC_Epic_OREvents.

2.4.1.3 Operations
 OPR_AS400_Cache_ChargingInpatientVerification: an SQL operation whose purpose is to have a log of all
records inserted in inpord. After calling OPR_AS400_DB2_InsertInpatientCharges, this operation is called. It
first selects the record inserted in inpord to make sure it exists, and then inserts it in the
PKGAS400.TempInpatientVerificationCharges table.

18
 OPR_AS400_Cache_DoctorGroupAdjustment: an SQL operation that inserts or updates in AS400 tables
(inpord or DocGrpAdj) depending on whether the patient class is inpatient and discharged or not, or outpatient.
Refer to this section for further details.
 OPR_AS400_Cache_ManageData: an SQL operation that retrieves information such as order number and
reference number from cache table PKGAS400.TempOutCharges.
 OPR_AS400_ChargingLookups: an SQL operation that retrieves information such as charge codes from
AS400 tables:
o QS36F.mixture and QS36F.drugvials for retrieving drug codes related to the vial.
o QS36F. inpord to retrieve clearance codes for inpatient procedures that require clearance.
 OPR_AS400_DB2_CancelAdmSurgReq: an SQL operation that calls an AS400 stored procedure
(AUH.ADMRSVCANC) to cancel the inpatient procedure clearance request when the order is cancelled in epic.
 OPR_AS400_DB2_CheckOROrder: an SQL operation that checks if a surgery pending order is already
registered upon documenting in room (by querying qs36f.inpord). The reason is to prevent having duplicate
entries for one surgery.
 OPR_AS400_DB2_GenerateRefNo: an SQL operation that inserts charges into PKGAS400.TempOutCharges
and returns the used reference and line number in order to use them to insert into qs36f.outpord.
 OPR_AS400_DB2_InsertDB2Charges: an SQL operation that mainly inserts, deletes, and retrieves data from
qs36f.outpord. The particular action depends on several conditions such as whether the charge message is a
new charge, a discount entry, or a refund. In addition, in case of a refund, it depends on whether the original
charge was cleared or not. This operation also inserts a record in outpordl for archiving purposes.
 OPR_AS400_DB2_InsertInpatientCharges: an SQL operation that mainly inserts, deletes, and retrieves
charges from qs36f.inpord. If a pending order is already registered for this charge, this operation deletes it.
Moreover, it inserts records in QS36F.INPORDL for archiving purposes.
 OPR_AS400_DB2_InsertInpatientOrder: an SQL operation that mainly registers a pending order or deletes it in
qs36f.inpord.
 OPR_AS400_DB2_ProcedureClearanceRequest: an SQL operation that calls an AS400 stored procedure
(AUH.INCLRREQC) to create/edit/delete an inpatient clearance request for surgeries or inpatient procedures
that need clearance.
 OPR_AS400_DB2_UpdateOROrder: an SQL operation that completes the pending order in qs36f.inpord
(added earlier when log event ‘in room’ is documented) once the log is posted by updating the value of srvbilled
to 1.
 OPR_AS400_DoctorGroupAdjustment: an SQL operation that inserts/updates tables:
QS36F.DocGrpAdj/QS36F.inpord with the completing doctor information.
 OPR_AS400_ED_DischargeOrder: This operation contains the methods for the ED discharge clearance;
checking AR balance, checking pending not cleared charges, storing discharge clearance flag in patientd and
EUPat.
 OPR_Cache_AS400_WriteData: an SQL operation that inserts/updates table: QS36F.outepicmap with data
from PKGAS400.TempOutCharges to synchronize the two tables together.
 OPR_FC_TCP_ORM: an HL7 operation that sends order clearance information from AS400 to the ‘incoming
orders clearance from AS400 [334317]’ interface in epic.
 OPR_NSPAgfa_TCP_ORM: an HL7 operation that sends order messages coming from
PRC_Epic_SendCArm_SIU to an ensemble service (SRV_Epic_HL7_CArm) in the NSPAgfa namespace.
 OPR_NSPMaterials_TCP_SIU: an HL7 operation that sends surgical scheduling messages coming from
PRC_AS400_ORCLearance and PRC_Epic_OREvents to an ensemble service (SRV_NSPAS400_HL7_SIU) in
the NSPMaterials namespace.

19
 OPR_NSPORPatientTrack_TCP_SIU: an HL7 operation that receives surgical scheduling messages from
PRC_Epic_SurgicalSIU_Router and sends them to an ensemble service (SRV_Epic_HL7_SIU) in the
NSPORPatientTrack namespace.

2.4.1.4 Data Transformations


 PKGAS400.DTLDFTInDB2Charges: Evaluates the DFT message and does the transformation needed to get
the fields needed to be inserted in outpord or inpord. Rules to note:
o Ordering Unit is set to EUD if patient is in ED. Otherwise set ordering unit same as the performing
unit which is the logged in user unit in most cases.
o For OR and Delivery charges set the performing unit as OR and DEL instead of the logged in user
since AS400 needs to identify surgical CPTs.
o If charge is supply, extract charge code from FT1-7 instead of FT1-25.
o If modifier contains the word “DISC”, extract and save discount amount to be sent to AS400.
o If modifier contains the word “INCISION”, extract and save incision number to be sent to AS400.
o The words “TRAUMA” and “INTERRUPTED” are also used to identify how to bill the surgery in
AS400.
o The leading ‘DR’ letters in the charge code identify vial medications.
o The phrase “Patient Population” in the NTE comments field is used to identify and extract the
charge pool code.
o For EKG charges, the phrase “PERFORMING DEPARTMENT” in the NTE comments field is used
to identify and extract the performing unit.
o If charge is related to willow, get the performing unit from the TBL_Pharmacy_Mapping table.
o If charge is related to pathology pool codes (09655,09650,09652) use order ID instead of UCL ID to
link to relevant order.
o When department is OPD, set doctor code as OPD.

 PKGAS400.DTLDFTRoutingCharges: Evaluates and does the below:


o If visit Type = "treat-inpatient" or Patient Class ="NEWBORN" => set patient Class = “INPATIENT”
o If Patient Class = "SURGERY ADMIT" OR "SAME DAY SUR" or empty => set Patient Class =
“OUTPATIENT”
o If one of the comments (NTE segments) contains UCL-250=”Procedure Category: CARDIAC
CATH" OR UCL-250=”Procedure Category: CV ELECTROPHYSIOLOGY PROCS” => set Patient
Class = “INPATIENT”
o If MSH-5 contains one of the oncology visit types (Evaluated from the lookup
“TBL_Treatinpatient_VisitTypes” ) => set patient Class = “INPATIENT”
o If Charge Type = "Cupid" for cardiac cath => set Patient Class = “INPATIENT ”

 PKGAS400.DTLORMInDB2Charges: Evaluates the ORM message and does the transformation needed to get
the fields needed to be inserted in outpord or inpord. Rules to note:
o Ordering Unit is set to EUD if patient is in ED. Otherwise set ordering unit as the enterer’s location
in most cases. Exceptions are explained below
o For EKG charges, the phrase “PERFORMING DEPARTMENT” in the NTE comments field is used
to identify and extract the performing unit.

20
o For contrast supplies, get the performing unit from the TBL_ContrastUnits table which is mapped to
the procedure category code.
o When department is OPD, set doctor code as OPD.
o Get guarantor from TBL_Guarantors table using the visit type.
o To identify if order is related to interventional radiology, filter on procedure category code = “18” or
OBR service identifier contains “IT_PROC” id type.
o To identify if order is related to pathology, filter on OBR diagnostic service = "Path,Cyt" or "AP Add-
on".
o Get grouping type from TBL_OrderGroupig using the OBR diagnostic service. This is needed to
group orders in OUTPord in a certain way as to simplify the bill generation at cashier’s side and for
insurance coverage purposes.
o Charge codes are extracted from NTE segments when these contain the following phrases:
 "PERFORMING DEPARTMENT"
 “Where will the procedure be done”
 "Supplies package to be used :"
 "Procedure will be done in"
 "Where will the procedure be performed"
 "Package to be used"
 "Advanced Femto Package"
 "Supply to be used"
 "ANESTHESIA NEEDED"
 "Type of Contrast"
 "Contrast Type"
 "RECONSTRUCTION CPT"
 "TIME FOR BOOKING THE "
 "Do you want to add DIBH ?->Yes"
 "Type of CT Simulation"
 "RadOnc Mask"
 "Perform Apheresis Procedure:"
 "Kit to be used"
 "Research Purposes"
o Doctor codes are extracted from NTE segments when these contain the following phrases:
 "Please specify the name of the consulted physician"
 "PERFORMING PROVIDER"
 "PATIENT POPULATION" Commented [RA9]: Confirm the term
 "PLEASE SPECIFY BILLING PROVIDER"
Commented [AA10R9]:
 "ORDERING PROVIDER SPECIALTY"
Commented [AA11R9]:
o Phenotype quantity is extracted from NTE segments when these contain the following phrases:
 "P1 Antigen->Yes"
 "Big C Antigen->Yes"
 "Small c Antigen->Yes"
 "Big E Antigen->Yes"
 "Small e Antigen->Yes"

21
 "Big K Antigen->Yes"
 "Small k Antigen->Yes"
 "Fya Antigen->Yes"
 "Fyb Antigen->Yes"
 "Jka Antigen->Yes"
 "Jkb Antigen->Yes"
 "Lea Antigen->Yes"
 "Leb Antigen->Yes"
 "M Antigen->Yes"
 "N Antigen->Yes"
 "Big S Antigen->Yes"
 "Small s Antigen->Yes"
 "D Antigen->Yes"
 "Kpa Antigen->Yes"
 "Kpb Antigen->Yes"
 "Lua Antigen->Yes"
 "Lub Antigen->Yes"
o Other phrases in NTE segments used to indicate discount percentage, lab test amount, addition of
cosmetic fee, suppressing charges, fetuses number, quantities, and portable charging include:
 "PROFESSIONAL FEES DISCOUNT"
 "WHAT IS THE PRICE OF THE TEST?"
 "Add Cosmetic Procedure Fee?->Yes"
 "Indicate the amount of money in L.L. to be added to the procedure professional fee for
cosmetic procedure done"
 "Is the medication patient supplied or AUBMC supplied?->patient supplied"
 "Number of Fetuses?->"
 "Portable?->Yes"
 "Number of CDM codes to be charged"
 "Do you want to charge the additional 5 mci ?"
 "Do you want to charge for the first ten mci ?"
 "Number of Tablets/Vials/Dose"
 "Number of tests used"
 "Number of times to replicate CPT code"
 "Bilateral"

 PKGAS400.DTLORMRoutingCharges: Evaluates certain fields in the ORM message such as patient class,
Value in PV2.Visit User Code, Value in MSH.Receiving Application to set the patient class in PV1.
 PKGAS400.DTLOutpordLogHL7ORM: Transforms the outpatient order clearance status coming from AS400
into an ORM message that is then used to update epic’s order clearance status.
 PKGAS400.DTLOutDBResponseHL7ACK: Transforms transaction response from AS400 to an
acknowledgment message that is sent to epic.

22
 PKGAS400.DTLInProcedureClearanceORM: Transforms the inpatient order clearance status coming from
AS400 into an ORM message that is then used to update epic’s order clearance status. Transformation table
TBL_ProcedureClearanceStatus is used to map AS400 clearance code to the value used for epic.
 PKGAS400.DTLAppointmentSIUInProcedureClearanceReqList: Evaluates the inpatient order (that needs
clearance) scheduling information and does the transformation needed to get the fields needed to call the
AS400 clearance request procedure. Transformation table TBL_CLearanceType is used to map Epic’s
procedure category code to the clearance type code used for AS400. Note that since only a subset of CT tests
(PET CTs) need clearance for inpatients, an id type (IS_PET) is set to “YES” for these tests and are filtered
accordingly by this transformation.

 PKGAS400.DTLInProcedureClearanceSIU: Transforms the surgical case clearance status coming from AS400
into an SIU message that is then used to update epic’s surgical case clearance status. Transformation table
TBL_ClearanceStatus is used to map AS400 clearance code to the value used for epic.
 PKGAS400.DTLORMInProcedureClearanceRequest: Transforms the ORM message to get the fields needed
to call the AS400 clearance request procedure. Note that this is used when the inpatient order is cancelled to
cancel the clearance request in epic. Transformation table TBL_CLearanceType is used to map Epic’s
procedure category code to the clearance type code used for AS400.
 PKGAS400.DTLS14InDB2Charges: Transforms the surgical case scheduling message to get the fields needed
to send a pending order to AS400 on ‘in room’ event or send ‘in room’/’out room’ events to OR patient tracking
application. Set ordering unit = ‘05S’ and order type = ‘CAT’ for cardiac cath, otherwise set ordering unit = ‘OR’
and order type = ‘SUR’ for OR.
 PKGAS400.DTLSIUORD: Transforms the surgical case-scheduling message to an ORM (admission order)
message when patient class is outpatient. Set OBR-4 = “CSC003” for pain management, “CSC002” for cardiac
cath, and “CSC001” for surgeries.
 PKGAS400.DTLSurgicalSIUInProcedureClearanceRequest: Transforms the surgical case-scheduling
message to get the fields needed to call the AS400 clearance request procedure.

Data Lookups
 TBL_ClearanceStatus: maps the inpatient OR clearance value coming from AS400 (5-Cleared, 9-Not Cleared) to
the Log event ID (ORL-650) in epic.
 TBL_ClearanceType: maps epic’s order category code (EAP-200) to the clearance type code in AS400 (1-OR, 2-
Radiology, 3-PET CT, 4-BMT). This is used for inpatient order clearance.
 TBL_ContrastUnits: maps epic’s order category code (EAP-200) to the order unit in AS400 (qs36f.dptunits). This
is used for contrast replenishment.
 TBL_EKGLocationMapping: maps the EKG order performing department in epic to the order unit in AS400
(qs36f.dptunits).
 TBL_GroupPoolCodes: maps the group pool codes in AS400 (qs36f.doctors) to the value ‘G’ to identify them.
 TBL_Guarantors: maps the visit type coming from epic to a guarantor code in AS400 (qs36f.guarant).
 TBL_Pharmacy_Mapping: maps the pharmacy code coming from Epic (PHR.1) to the AS400 ordering unit
(qs36f.dptunits).
 TBL_ProcedureClearanceStatus: maps the clearance status coming from AS400 (5-Cleared, 9-Not Cleared) to
epic’s clearance value.
 TBL_Treatinpatient_VisitTypes: maps the visit types that should be treated as inpatient visits in terms of charging
to the value ‘INPATIENT’.

23
Cache DB Tables
 PKGAS400.TempOutCharges: A transient table used to store outpatient charges’ information coming from epic
in order to generate reference numbers and line numbers before sending to AS400. It is also used to store
clearance information.
 PKGAS400.TempDocGrpAdjError: An error log table used to store any ensemble error related to replacing pool
code values with specific physician codes.

3 OPTIMIZATION TOPICS

24