| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
| 3498 | DBIA3498 | Routine | COMMUNICATIONS SERVICE LIBRARY | 2001/12/26 | APPROVED | Active | Controlled Subscription | Build an SIU transaction of patient schedule to transmit to DynaMed. This function is meant to be called in foreground, not background as messages will be displayed to the user. If the transaction is built successfully, the function will display this fact with the Message Control ID. If the transaction cannot be built, the function will display the fact that nothing was built, and the reason this occurred. After the message displays, the user will be expected to hit the <return> or <enter> key to continue. |
CSLSUR1 | |||
| 3514 | DBIA3514-A | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/08/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis, and the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB40 | |||
| 3515 | DBIA3514-B | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/11/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis, and the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB14 | |||
| 3516 | DBIA3514-C | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/08/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis, and the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB16 | |||
| 3517 | DBIA3514-D | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/08/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis, and the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB39 | |||
| 3518 | DBIA3514-E | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/08/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis; and to define the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB25 | |||
| 3610 | coreFLS PURCHASE ORDER | Other | COMMUNICATIONS SERVICE LIBRARY | 2002/07/02 | Withdrawn | Private | This global subtree of ^XTMP contains data for a Single Patient, Approved Purchase Order created in coreFLS and sent to VistA Prosthetics for processing. The COMMUNICATIONS SERVICE LIBRARY package sets up this global upon receipt of the HL7 ORM^O01 message and the PROSTHETICS package then extracts the data. MCID is the Message Control ID from the HL7 message's MSH segment. GLOBAL REFERENCES: ^XTMP("CSLPRPO;"_MCID,0)=Purge date^Create Date^"PO Sent from coreFLS to VistA" ^XTMP("CSLPRPO;"_MCID,"CONSULT")=Consult ID^Inpatient or Outpatient ^station ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"ACCOUNTING")=ACS^Alias^Purchase Card Number ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DELIVERY")=Location Code^Location Description^Date Needed ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",1)=PO_LINE_ID^ITEM_ID (internal item number)^SEGMENT1 (external item number)^Quantity^Unit code;name^Unit Price ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",2)=Manufacturer code;name^Vendor Product Number^Contract Number ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",3)=HCPC Code^NPPD Line ^Patient Category^Transaction Type ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",4)=Date Last Edited ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",5)=Line Counter^"ITEM DESCRIPTION" ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",5,counter,0)=Description Text ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",6)=Line Counter^"NOTE TO SUPPLIER" ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",6,counter,0)=Note to Supplier Text ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",7)=Line Counter^"NOTE TO RECEIVER" ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",7,counter,0)=Note to Receiver Text ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",8)=Line Counter^"ITEM ATTACHMENT" ^XTMP("CSLPRPO;"_MCID,"ITEM",counter,"DETAIL",8,counter,0)=Item Attachment Text ^XTMP("CSLPRPO;"_MCID,"ORDER CONTROL")=Order Control^Reason ^XTMP("CSLPRPO;"_MCID,"PO",1)=SEGMENT1 (external PO number)^ PO_HEADER_ID (internal PO number)^Station^ORG_ID^Enter Date^ Enter Agent SSN^Approved Date^Action Agent SSN^Lastname^First Name^ Middlename^Suffix ^XTMP("CSLPRPO;"_MCID,"PO",2)=Authorization Status^Version Number^Version Date ^XTMP("CSLPRPO;"_MCID,"PO",4)=Line Counter^"COMMENTS" ^XTMP("CSLPRPO;"_MCID,"PO",4,counter,0)=Comments Text ^XTMP("CSLPRPO;"_MCID,"PATIENT")=ICN^'NI' or 'LR'^Station^DFN^Station ^SSN^Lastname^Firstname^Middlename^Suffix ^XTMP("CSLPRPO;"_MCID,"PPA")=SSN^Lastname^Firstname^Middlename^Suffix ^XTMP("CSLPRPO;"_MCID,"SHIPPING",1)=Location Code^Address Line1^Address Line2 ^XTMP("CSLPRPO;"_MCID,"SHIPPING",2)=City^State^Zip Code ^XTMP("CSLPRPO;"_MCID,"SHIPPING",3)=FOB^Ship to Terms^S&H Charges ^Currency^Shipping PO_LINE_ID ^XTMP("CSLPRPO;"_MCID,"VENDOR","ADDRESS")=Address Line1^Address Line2^City^State^Zip Code ^XTMP("CSLPRPO;"_MCID,"VENDOR","ID")=Name^ID Number ^XTMP("CSLPRPO;"_MCID,"VENDOR","PHONE")=Voice^Fax ^XTMP("CSLPRPO;"_MCID,"ZERRORS",counter)=Error description Note: All dates are in FileMan format, converted from HL7 date format, if necessary. |
|||||
| 3740 | Vendor Query (for CoreFLS) | Routine | COMMUNICATIONS SERVICE LIBRARY | 2002/09/12 | APPROVED | Active | Controlled Subscription | Vendor Query ------------- Purpose: To allow a user to query CoreFLS for a vendor matching a given set of search criteria Behavior: The user is prompted for prompted for one or more query strings, as follows. >D VENQ^CSLVQ(.out,"NCS","A") Vendor Name: CITI City: San Francisco State: CA Any matching values are displayed to the user in the style of ^DIC. Each matching value will have an associated multiline identifier consiting of the vendor address. Once the user selects a record, the "out" array will be populated with the set of attributes for that vendor reurned by CoreFLS (for details, see "OUTPUT" below). The set of fields for which the user will be prompted is controlled by the second parameter to the vendor query (see below under "Syntax"). If no parameters are supplied, the default is to query for name only. Any fields for which the user supplies no value are ignored, otherwise, the search criterion will be the Boolean AND of the supplied parameters (i.e., each field must match). By default, if the user enters an unquoted string, it will be intepreted as a (case sensitive) initial substring. Thus, CITI matches CITIBANK, but Citi will not. (In this case, if the user enters CITI, the string actually sent to CoreFLS is "CITI%"). As an alternative, users may enter either exact matches or patterns involving the SQL wildcard characters '%' and '_' in quotes. E.g., Vendor Name: "CITI%NK" City: "L_s Ang%es" Example: Vendor Name: "%TEMS%" . . . . . . . . Choose from: 1 ACCESS SYSTEMS 1116 SMITH ST CHARLESTON, WV 25301 2 BARD ACCESS SYSTEMS 5425 W AMELIA EARHART DR SALT LAKE CITY, UT 84116-3713 etc. Select QUERY RESULTS SEQ NO: 2 BARD ACCESS SYSTEMS 5425 W AMELIA EARHART DR SALT LAKE CITY, UT 84116-3713 Syntax: D VENQ^CSLVQ(.out,flags,display_flags) INPUT This call has three parameters, a reference to an array that will be populated with the attributes of the selected vendor, a scalar variable containing 0 or more flags indicating which fields should be used as input parameters/searchable fields, and a scalar variabld containing 0 or more flags controlling what will be displayed to the user as identifying text (i.e., as Fileman identifiers). The format of the output array is described below under "OUTPUT". The second parameter may contain any combination of the following flags (order is unimportant): N = Name n = Vendor Number a = Area Code p = Phone Number C = City S = State T = Tax ID/SSN 1 = Address Line 1 2 = Address Line 2 3 = Address Line 3 P = Postal Code c = Chain number For example, to query by name and SSN, use "NT". If this parameter is omitted (or if it is equal to the empty string), the default is to search by name only. However, if a value is supplied, "N" will not be automatically added to the list. Thus, "T" will cause the user to be prompted for Tax ID only. The display_flags parameter may contain any combination of the following flags (again, order is unimportant): n = CoreFLS Vendor ID / CoreFLS Site ID A = address t = telephone no. T = Tax ID C = Chain no. P = Participation code a = Attributes (Purchasing, Pay-to, etc.) Note: If the "n" flag is included, the CoreFLS vendor ID and CoreFLS site ID will appear on the first line of the identifying text displayed for that vendor with the vendor name immediately below. If this parameter is missing or null, the default is to display only address information (i.e., the default is "A"). OUTPUT A single array is passed by reference ("out" in the above syntax example). If the user selects a vendor, the array will be populated with the attributes of that vendor as follows: out("NAME") - Vendor name out("NUMBER") - numeric vendor ID out("INACTIVE") - vendor will be inactive after this date (FM format) out("TAXID") - Tax ID out("AREA_CODE") - area code out("PHONE") - phone number out("FAX_AREA_CODE") - FAX area code out("FAX") - FAX number out("ADDRESS1") - address line 1 out("ADDRESS2") - address line 2 out("ADDRESS3") - address line 3 out("CITY") - City out("STATE") - State out("COUNTY") - County out("ZIP") - Postal code out("COUNTRY") - Country out("SITE_CODE") - Site Code out("CHAIN_NO") - Chain Number out("COMMENTS") - Comments out("PARTICIPATION_CODE") - Participation Code out("LAST_UPDATED") - date vendor record last updated on CoreFLS In addition, there are a number of optional vendor attributes. If an attribute is present, the appropriate top level subscript will be set. For example, for an EDI vendor, we will have out("EDI_VENDOR")=1 The complete list of attribute subscripts is ON_HOLD PRIMARY_PAY_TO RFQ PURCHASING PAY_TO PROCUREMENT_CARD PRICER_EXEMPT FEE_VENDOR EDI_VENDOR PO_HOLD NEW_PAY_HOLD ALL_PAY_HOLD Fields have no value will not appear in the out array Errors: If an error should occur during the query, the node out("ERROR") will be set. There are two special cases: Network timeout - In this case, out("ERROR")="NETWORK TIMEOUT" No Selection - If the user does not select a vendor (e.g., by exiting by typing "^") it will be the case that out("ERROR")="NO SELECTION" In all other cases, out("ERROR") will be set to the error message returned by CoreFLS or possibly to a value indicating an internal error in the Communications Service Library (the specific value being a string indicating the nature of the error). Caveat: Note that the vendor query API does not clear the out variable, so it is best to explicitly NEW this variable (which should be namespaced) before making the call. |
CSLVQ | |||
| 3782 | Vendor Update API | Routine | COMMUNICATIONS SERVICE LIBRARY | 2002/10/10 | APPROVED | Active | Controlled Subscription | Vendor Update API The vendor update operates asynchronously using a callback model. The first step in running the vendor update is to build a (typically global) array containing the vendor ID, site ID and modification date for each vendor to be updated. In addition to the asynchronous (background) entry point, there is a synchronous (foreground) call that may be used to interactively retrieve the full set of attributes that would be returned for a vendor using the background update. The foregound call involves no modification date, and returns the vendor attributes unconditionally. The format of the array is ... ARRAY(index) = vendor_id^site_id^timestamp ... (where timestamp is in Fileman format). Note: The timestamp will be the value previously received from CoreFLS, not the time the local file was updated or any other timestamp generated within VistA. Example: ^TMP(4375,1)="ACME_DRUGS_AND_SUPPLIES^SAN_FRANCISCO_2^3021008.191213" ^TMP(4375,2)="PEERLESS_AMBULANCE_CO^ATLANTA_7^3020721.1542" The name of this array (not a reference) will be one parameter to the vendor update. Example: In this case, the array name is $NA(^TMP(4375)), or simply "^TMP(4375)". The second parameter will be an entry point to user supplied routine in the format "ENTRY^ROUTINE" (i.e., no parameters will be listed). The actual call is D UPDATE^CSLVQ(ARRAY,"ENTRY^ROUTINE") The array passed as the first parameter may safely be KILLed by the caller at any point after this call returns. If an error occurs, CSLERR will be set a value in the format "errno^description". The callback has one parameter, the name of an array containing one or more vendor records. The format of the array is ARRAY(index, field_subscript) = value Exception: Index value 0 is reserved for system use, so ARRAY(0, ...) must not be treated as data. Typically, data will be stored under numeric subscripts starting with 1. The possible values of field_subscript are VENDOR_ID VENDOR_NAME TAX_ID INACTIVE_DATE [1] AREA_CODE PHONE_NO FAX_AREA_CODE FAX_NO ADDRESS_LINE_1 ADDRESS_LINE_2 ADDRESS_LINE_3 CITY STATE COUNTY POSTAL_CODE COUNTRY VENDOR_SITE CHAIN_NO COMMENTS [2] LAST_UPDATED [1] PARTICIPATION_CODE VENDOR_TYPE TYPE_OF_VENDOR MEDICARE_ID SPECIALTY_CODE NO_OF_BEDS INSPECTED/ACCREDITED LAST_ASSESSMENT [1] CERTIFIED_MEDICARE/MEDICAID ON_HOLD FEE_VENDOR Notes: [1] Dates are Fileman format [2] A word-processing field will be stored in the format SUBARRAY(1,0)=line 1 SUBARRAY(2,0)=line 2 ... For example, the comments field might be stored as ^TMP(1,34567830,"COMMENTS",1,0)="Line 1 of comments ^TMP(1,34567830,"COMMENTS",2,0)="Line 2 of comments In addition, there are a number of optional vendor attributes. If an attribute is present, the appropriate top level subscript will be set. For example, for an EDI vendor, we will have ARRAY(index,"EDI_VENDOR")=1 The complete list of attribute subscripts is ON_HOLD PRIMARY_PAY_TO RFQ PURCHASING PAY_TO PROCUREMENT_CARD PRICER_EXEMPT FEE_VENDOR EDI_VENDOR PO_HOLD NEW_PAY_HOLD ALL_PAY_HOLD WARNING It is the responsibility of the user supplied routine to file the data, performing any necessary locking. It is important to be aware that this routine can be called at any time, and it is possible for it to be called any number of background tasks running concurrently. A second entry point ("interactive update") exists as a convenience to the user/programmer. This entry point is an extrinsic function ($$IUPDT^CSLVQ) taking the vendor ID and vendor site name as parameters and returning he name of an array containing the vendor attributes (in the same format). In this case, no date of last update is supplied, and the vendor data is returned unconditionally. |
CSLVQ | |||
| 3834 | CSL Cost Center table update | Routine | COMMUNICATIONS SERVICE LIBRARY | 2002/11/05 | APPROVED | Active | Controlled Subscription | With the replacement of IFCAP by the CoreFLS system, the lookup of a Cost Center value will be done through a local Cost Center file. This file will be updated by Event Capture once a year or as needed through a query to retrieve active cost centers from the CoreFLS system. According to VA handbook 4671.1, cost center codes from 8000** through 8999** will cover all possible VHA activities. The cost center file update query will issue a request to the CoreFLS system to transmit all cost center codes which start with an 8 (8*****) to VistA. The CC table update query function call provided to the subscriber will return a value of 1 indicating the query sent to CoreFLS system was successful, or a 0 to indicate the query failed. Example: S X=$$CCTBL^CSLEC() to send CC table update query to CoreFLS system After CC table update query is received by the CoreFLS system, an HL7 message containing all the cost center codes that start with an 8 (8*****) will be generated and transmitted to VistA for processing. The HL7 package in VistA will invoke routine CSLEC1 to parse the HL7 message and store the most recent active cost center codes into table 536.3. Before the table is updated, the active flag for all cost center codes in the table will be changed to 0 (inactive). If an existing cost center is included in the HL7 message received, the active flag will be updated to 1 (active). To prevent table 536.3 from being partially updated while processing the HL7 messages, the data will be parsed to a temparary file ^XTMP first then to the file 536.3. In order to decide whether the CC table update is successful or not, the subscriber need to check the 5 parameters provided by the CC table update query. The following 5 parameters will be defined in file 8989.51 through the pre-install routine, CSLEC2, when the CSL package is installed at site for the first time. The value of these parameters are stored in file 8989.5 and will be updated each time the CC table update query is invoked. 1. CSL CC UPDATE REQUEST (store the query request date) 2. CSL CC UPDATE START (store the table update start date) 3. CSL CC UPDATE END (store the table update end date) 4. CSL CC UPDATE STATUS (1: processing, 0: completed) 5. CSL CC UPDATE NOTE (store status note) The following logic decide whether the update is successful or not: If Request date > Start date Start date > End date table partially updated and data is not usable Start date <= End date table not updated but data is usable. If Request date <= Start date Start date > End date table partially updated and data is not usable. Start date <= End date table updated successfully |
CSLEC | |||
| 3850 | Fund Query | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/06/02 | APPROVED | Active | Controlled Subscription | Fund Query ---------- Purpose: To allow a user to query coreFLS for funds matching a given query string. Behavior: The user is prompted for a query string as follows Fund: and then enters a string that will be used to query coreFLS. Any matching values are displayed to the user in the style of ^DIC. A fund may then be selected. Example: >D FUNDQ^CSLARACS Fund: 8180 . . Choose from: 1 8180DA100XXXX GENERAL POST FUND-ALLOCATION 2 8180DG100XXXX GENERAL POST FUND-GENERAL 3 8180DM100XXXX OFFICE OF SECRTY-MUSEUM FUND 4 8180DS100XXXX GENERAL POST FUND-SPECIFIC 5 P8180DA100XXX 8180DA100XXXX 6 P8180DS100XXX 8180DS100XXXX Select QUERY RESULTS SEQUENCE NO: 1 8180DA100XXXX GENERAL POST FUND-ALLOCATIO N >W CSLY 8180DA100XXXX > Syntax: D FUNDQ^CSLARACS This call has no input variables or parameters |
CSLARACS | |||
| 3851 | BOC/RSC Query | Routine | COMMUNICATIONS SERVICE LIBRARY | 2002/11/22 | Withdrawn | Controlled Subscription | BOC/RSCQuery ---------- Purpose: To allow a user to query coreFLS for BOC or RSC matching a given query string. Behavior: The user is prompted for a query string as follows RSC: and then enters a string that will be used to query coreFLS. Any matching values are displayed to the user in the style of ^DIC. A fund may then be selected. Example: >D BOCQ^CSLARACS BOC/RSC: R101 . . . 1 R10100 INTEREST REVENUE Select QUERY RESULTS SEQUENCE NO: 1 R10100 INTEREST REVENUE Syntax: D BOCQ^CSLARACS This call has no input variables or parameters |
CSLARACS | ||||
| 3852 | CSL Cost Center file 536.3 | File | COMMUNICATIONS SERVICE LIBRARY | 2002/11/25 | APPROVED | Active | Controlled Subscription | 536.3 | Event Capture utilizes the Cost Center during the setup of the DSS Units in the Event Capture package. With the replacement of IFCAP by the CoreFLS system, the lookup of a Cost Center value will be done through a local Cost Center file which will be updated by Event Capture once a year or as needed through a query to retrieve active cost center from the CoreFLS system. The CSL Cost Center file, 536.3, contains 3 fields: Cost Center Code, description, and Active Flag. |
|||
| 3891 | This is a Test | Remote Procedure | COMMUNICATIONS SERVICE LIBRARY | 2003/02/12 | Withdrawn | Private | csl | |||||
| 4124 | DBIA3514-F | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/08/12 | APPROVED | Retired | Controlled Subscription | Define the use of the CSL API to be called by Fee Basis, and the use of ^XTMP by CSL in the interface between Fee Basis and CoreFLS. |
CSLFB38 | |||
| 4224 | Controlled subscription from AR to CSL via CSLARBC routine | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/09/04 | APPROVED | Active | Controlled Subscription | CoreFLS will replace three VistA applications - IFCAP, AEMS/MERS, and FMS which is the central accounting software used in the VA. Hence, VistA applications, which used to communicate with these applications, will now communicate with the COTS applications in CoreFLS. To be able to provide real-time integration between CoreFLS and VistA, HL7 messaging protocol was selected. This integration agreement will address the CSL interface application linking the VistA AR system with the Oracle based CoreFLS financial system. |
CSLARBC | |||
| 4233 | COST CENTER QUERY | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/09/02 | Withdrawn | Controlled Subscription | Allow user to query CoreFLS for cost centers matching an input pattern. |
CSLARACS | ||||
| 4234 | FIELD ACTIVITY QUERY | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/09/02 | Withdrawn | Controlled Subscription | allow users to query CoreFLS for field Activity values from the Accounting Code String (ACS) based on input key. |
CSLARACS | ||||
| 4235 | Controlled subscription from AR to CSL via CSLARSV routine | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/09/04 | APPROVED | Active | Controlled Subscription | CoreFLS will replace three VistA applications - IFCAP, AEMS/MERS, and FMS which is the central accounting software used in the VA. Hence, VistA applications, which used to communicate with these applications, will now communicate with the COTS applications in CoreFLS. To be able to provide real-time integration between CoreFLS and VistA, HL7 messaging protocol was selected. This integration agreement will address the CSL interface application linking the VistA AR system with the Oracle based CoreFLS financial system. |
CSLARSV | |||
| 4236 | Controlled subscription from AR to CSL via CSLARDR routine | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/09/04 | APPROVED | Active | Controlled Subscription | CoreFLS will replace three VistA applications - IFCAP, AEMS/MERS, and FMS which is the central accounting software used in the VA. Hence, VistA applications, which used to communicate with these applications, will now communicate with the COTS applications in CoreFLS. To be able to provide real-time integration between CoreFLS and VistA, HL7 messaging protocol was selected. This integration agreement will address the CSL interface application linking the VistA AR system with the Oracle based CoreFLS financial system. |
CSLARDR | |||
| 4255 | CSL REFERENCING PARAMETERS | Other | COMMUNICATIONS SERVICE LIBRARY | 2003/10/28 | APPROVED | Active | Controlled Subscription | CSL created the following 5 parameter entries, which will be referenced by Event Capture usen parameter tools: 1. CSL CC UPDATE REQUEST (store the query request date) 2. CSL CC UPDATE START (store the table update start date) 3. CSL CC UPDATE END (store the table update end date) 4. CSL CC UPDATE STATUS (1: processing, 0: completed) 5. CSL CC UPDATE NOTE (store status note) |
||||
| 4296 | DBIA4296 | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/11/18 | Withdrawn | Controlled Subscription | Silently (i.e. without user interaction) receive input from a calling program for building a vendor query. The input would be in a structured local array as in CLSIN shown below. CSLPRVQ* would use the input to build an HL7 message, obtain the Message Control ID (MID), and send the message to the CoreFLS database. When the results of the query were returned by HL7, CSLPRVQ* would build an ^XTMP(SUB) global with that data. SUB equals the string "CSLPRVQ" concatenated with the MID (ex. "CSLPRVQ516124898"). The expected structure of the input array (CSLIN) is as follows: CSLIN(2.1) - VENDOR NAME CSLIN(2.2) - TAX ID CSLIN(2.3) - CITY CSLIN(2.4) - STATE CSLIN(2.5) - VENDOR SITE CSLIN(2.6) - VENDOR ID CSLIN(2.7) - AREA CODE CSLIN(2.8) - PHONE NO CSLIN(3.1) - ADDRESS 1 CSLIN(3.2) - ADDRESS 2 CSLIN(3.3) - ADDRESS 3 CSLIN(4) - ZIP CSLIN(5) - CHAIN NO Note that if any of the above nodes are not defined or are set to NULL then those fields will not be used in composing the query. The data in every field that is defined will have the "%" wildcard appended to it. For example, if CSLIN(2.1)="MED" then the value "MED%" will be used in building the query. An example of the structure of the output array (^XTMP(SUB)) appears below, where SUB is as described above and N holds the information for the Nth result returned from CoreFLS: ^XTMP(SUB,N,"ADDRESS1")=2010 59TH ST W STE 4700 ^XTMP(SUB,N,"ATTRIBUTES",1,"CODE")=4 ^XTMP(SUB,N,"ATTRIBUTES",1,"DESCRIPTION")=PURCHASING SITE ^XTMP(SUB,N,"ATTRIBUTES",2,"CODE")=5 ^XTMP(SUB,N,"ATTRIBUTES",2,"DESCRIPTION")=PAY-TO-SITE ^XTMP(SUB,N,"CITY")=BRADENTON ^XTMP(SUB,N,"COUNTRY")=US ^XTMP(SUB,N,"COUNTY")= ^XTMP(SUB,N,"INACTIVE")=3031010.24 ^XTMP(SUB,N,"LAST_UPDATED")=3010917.10344 ^XTMP(SUB,N,"NAME")=MED ARTS REHAB INC ^XTMP(SUB,N,"NUMBER")= ^XTMP(SUB,N,"SITE_CODE")=BRADENTON-FL-00 ^XTMP(SUB,N,"STATE")=FL ^XTMP(SUB,N,"TAXID")=592199074 ^XTMP(SUB,N,"ZIP")=342094687 Note that each subscript shown above will be defined in the output array even if that node contains no data (as in ^XTMP(SUB,N,"COUNTY") above). The first 50 results of the query will be returned in the ^XTMP(SUB) global. Because ^XTMP is used to hold the query results, the results would be deletable after 7 days. The entry point for the silent vendor query: >W $$CSVQ^CSLPRVQ(.CSLIN) where CSLIN is an array structured as shown above. If the query runs successfully, the return value will look like "^CSLPRVQ516124898". If the query encounters an error condition, the return value will look like "3^Not Found", with a positive number in the first "^"-peice and a short descriptive message of the error in the second "^"-peice. The different possible errors along with comments are shown below. CSLPRVQ* would return the ^XTMP subscript SUB as described above to the calling application in the format "^SUB". If the first "^"-piece is nonzero then an error occurred and the second "^"-piece will contain an error message. The list below shows the error messages that could be returned along with comments. Note that these error messages, unless specified in the comments to the right, will appear as the return value for the routine call described above. Invalid input parameter list HL7 error - the input message string sent to CoreFLS was invalid Query aborted due to error: HL7 error when initializing HL7 parameters Message send failure: HL7 error when transmitting message to CoreFLS Network Timeout the query request to CoreFLS timed or the check for results in ^XTMP timed out Not Found no results obtained for query in CoreFLS 104^wrong segment name HL7 errors when processing 201^application error incoming response from 202^application reject CoreFLS - these will appear in 401^missing segments nodes ^XTMP(SUB,"ERR"), 402^ERR segment received ^XTMP(SUB,"ETEXT"), and 403^wrong segment name (expected QAK) ^XTMP(SUB,"ENUMBER"). 404^missing segments 407^RDT segments expected 408^wrong segment name (RDT expected) 500^Can't find entry in ITEM QUERY file 999^unknown error wrong number of columns 900 a general error occurred. this will also be in ^XTMP(SUB) |
CSLPRVQ | ||||
| 4310 | Sub-Organization Query | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/12/09 | Withdrawn | Controlled Subscription | Allow the user to query CoreFLS for sub-organization matching a given query string. |
CSLARACS | ||||
| 4311 | Query for Part 2 & 3 of Program String | Routine | COMMUNICATIONS SERVICE LIBRARY | 2003/12/09 | Withdrawn | Controlled Subscription | CSLARACS | |||||
| 4336 | AP Status Update (from CoreFLS to VistA Prosthetics) | Routine | COMMUNICATIONS SERVICE LIBRARY | 2004/02/09 | APPROVED | Active | Private | AP Status Update Purpose: To transmit a message from CoreFLS to VistA Prosthetics when a value on a Prosthetics Purchase Order has been changed, either because of an Invoice transaction, a price or quantity change on a PO. or a reconciliation of a line item or the cancellation of a PO or the completion of a PO. Behavior: There is no user prompting in this event. All information is transmitted by CoreFLS. When the event occurs, a message is sent to VistA Prosthetics via CSL. Upon receipt, an Application Acknowledgement ACK or NAK is returned to CoreFLS. Information is transmitted from CoreFLS in an HL7 format specified as "AP Status Update Event from CoreFLS". Incoming information is read by routines ~CSLPRUP and ~CSLPRUPA. If the Order Status Field is "CA", the message is considered a cancellation of the entire PO; otherwise, the message is a transmission of a change to a specific line on a specified PO. Information that is transmitted from CoreFLS is put into an ^XTMP global for use by VistA Prosthetics. The CSL routine calls a VistA routine, EN~RMPRCSL1(CSLSUB,.ERRAY), passing the complete node structure of "CSLAPUP" concatenated with the Message Control ID, for processing, plus any content or format errors that the CSL code has identified. NOTE: Quantity Invoiced and Invoice Line Amount are assumed to be transmitted from CoreFLS as running totals for the line item on the PO. This means that if 15 units were ordered and they were invoiced as they arrived as 1, 2, 3, 4 then 5 items, there would be 5 AP Status Update messages. The first would reflect a quantity of 1, the second would be 3, the third would 6, the fourth would be 10, and the fifth would be 15. If the message transmitted is a cancellation of a complete Purchase Order, the CSL process branches to ~CSLPRUPC to develop the ~XTMP global with less data in the global but with the same structure. CSL invokes the same processing routine for sending information to VistA Prosthetics. The CSL routine evaluates the data sent by CoreFLS for the following structure and content: PO Number longer than 20 characters Quantity Ordered not numeric PO Line number not numeric ACS longer than 200 characters Quantity Invoiced not numeric Purchase card longer than 80 characters PO Line ID not numeric Unit price not numeric Vendor Number longer than 30 characters Vendor Site longer than 15 characters Update Date not formatted correctly Line Cancelled Quantity not numeric Invoice Line Amount not numeric Order Line Amount not numeric After VistA Prosthetics processes the supplied information, if an error is detected, an error message is returned to CSL in sub-node 5 of the ~XTMP global. This causes an Application NAK to be transmitted to CoreFLS for evaluation and reprocessing. If no errors are detected, either by CSL or by VistA Prosthetics, then an Application Acknowledgement ACK is sent from CSL to CoreFLS. This completes the activities for AP Status Update |
||||
| 4339 | Prosthetics Purchasing Event | Routine | COMMUNICATIONS SERVICE LIBRARY | 2004/02/25 | APPROVED | Active | Controlled Subscription | Agreed upon format for handoff and return between VistA Prosthetics and CSL for the Prosthetics Purchasing interface event. |
CSLPRPP | |||
| 4340 | DBIA4340 | Routine | COMMUNICATIONS SERVICE LIBRARY | 2004/02/09 | APPROVED | Active | Controlled Subscription | Item Query is a silent query which receive inputs from calling program for building a query. The inputs would be in a local array as in OUT shown below. CLSPRIT* would use the input to build an HL7 message, obtain the message Control ID (MID), and send the message to the CoreFLS Oracle database. Once the query results were returned, CSLPRIT* would build a ^XTMP(SUB) with that data. |
CSLPRIT | |||
| 4341 | Prosthetics Purchase Order Creation | Routine | COMMUNICATIONS SERVICE LIBRARY | 2004/02/18 | APPROVED | Active | Private | PO Creation is to transmit a message from CoreFLS to VistA Prosthetics when a Prosthetics Purchase Order has been created in CoreFLS. There is no user interface in this event. All data is transmitted by CoreFLS. When the event event occurs, a message is sent to VistA Prosthetics via CSL. Upon receipt, an Application Acknowledgement ACK or NAK is returned to CoreFLS. Information is transmitted from CoreFLS in an HL7 format. Incoming info is read by routine CSLPRPC. If the Order Status is "NW", a PO is created in CoreFLS successfully. If the Order Status is "DE", a PO has an error and not created in CoreFLS. Information from CoreFLS is put into a global ^XTMP for use by VistA Prosthetics. |
CSLPRPC* |