| DESCRIPTION OF ENHANCEMENTS |
This Outpatient Pharmacy patch is part of the Patient Financial Services
replacement system. The project consists of the implementation of the
defined, that value will be passed to the COTS billing system for all
division having prescriptions filled. If the CHARGE LOCATION is not
defined for any division and the PFSS switch is turned on, the
prescription information will not pass to IB or the COTS billing system.
Technical Description:
======================
At FINISH of the prescription fill:
billing replacement system, business process improvements, and
1. The new IB API #4664 GETACCT^IBBAPI will be called to request a PFSS
ACCOUNT REFERENCE and it will be stored in the PRESCRIPTION file (#52) on
the fill level. For original fills, it will be stored in the PFSS ACCOUNT
REFERENCE field (#125), and for refills it will be stored in the PFSS
ACCOUNT REFERENCE field (#21). These references uniquely identify the
prescription to the COTS billing system.
2. The array of data passed using the GETACCT^IBBAPI call encompasses all
of the minimum required data elements as stated in the PFSS SRS-SDD IBB
enhancements to VistA to support integration with the COTS billing
Generic API document. The following outlines data passed from
Outpatient Pharmacy:
$$GETACCT^IBBAPI(VAR1,VAR2,VAR3,VAR4,.ARR1,,,.ARR4,.ARR5,VAR5,,)
Where:
VAR1 = Patient Identifier (Patient IEN)
VAR2 = PFSS Account Reference
VAR3 = HL7 Event Code
VAR4 = Application Location Reference
ARR1 = ARR1(2) Patient Class, ARR1(3) Patient Location,
replacement system. Significant changes to VistA legacy systems and
ARR1(7) Attending Physician, ARR1(44) Admit
Date/Time (Fill Date), ARR1(50) Alternant Visit
ID (Prescription IEN)
ARR4 = ARR4(n,3) Diagnoses Code, ARR4(n,6) Diagnosis Type
ARR5 = ARR5(n,2) Type
VAR5 = Medical Center Division
3. After IB returns the PFSS ACCOUNT REFERENCE to Outpatient Pharmacy,
IB will pass the GETACCT information to the COTS billing system via the
VistA Data Extraction Framework (VDEF) and will store the returned PFSS
ancillary packages are necessary.
Account Number external value in the PFSS ACCOUNT file (#375).
At RELEASE of the prescription fill:
1. The new IB API # 4665 GETCHGID^IBBAPI will be called to request a PFSS
CHARGE ID. This information is used to uniquely identify the fill in the
IB and will be stored in Prescription file (#52) on the fill level. For
original fills, it will be stored in the PFSS CHARGE ID field (#126), and
for refills it will be stored in the PFSS CHARGE ID field (#22). No data
is passed using this API.
2. Next, the new IB API #4665 CHARGE^IBBAPI will be called to pass
prescription and copay information. This information will be stored in
the PFSS CHARGE CACHE file (#373). IB will batch the charge information
and pass it on to the COTS billing system via VDEF.
3. The array of data passed using the CHARGE^IBBAPI call encompasses all
of the minimum required data elements as stated in the PFSS SRS-SDD IBB
Generic API document. The following outlines data passed from Outpatient
Some of the PFSS software components are not operational until the PFSS
Pharmacy:
$$CHARGE^IBBAPI(VAR1,VAR2,VAR3,VAR4,.ARR1,,.ARR3,.ARR4,.ARR5,,,)
Where:
VAR1 = Patient Identifier (Patient IEN)
VAR2 = PFSS Account Reference
VAR3 = Charge Type
VAR4 = Unique Charge ID (PFSS Charge ID)
ARR1 = ARR1(4) Transaction Date (Fill Date), ARR1(7) Transaction
Code, ARR1(10) Transaction Quantity, ARR1(13) Department
On/Off Switch, distributed with patch IB*2*260, is set to "ON". The
Code, ARR1(18) Patient Copay Status, ARR1(21) Ordered by
Code, ARR1(22) Unit Cost, ARR1(29) NDC_";"_Generic
Name, ARR1(31) Copay Transaction Type
ARR3 = ARR3(n,3) Diagnoses Code, ARR3(n,6) Diagnosis Type
ARR4 = ARR4(n,2) Type
ARR5 = ARR5(1) Quantity_";;"_Days Supply, ARR5(17) Refills
Dispensed (Fill Number), ARR5(18) Date of Most Recent
Fill (Release Date), ARR5(31) DEA, Special Handling
4. There will be no return messaging from the COTS billing system to
ability for the local site to set the switch to "ON" will be provided at
Outpatient Pharmacy. Note that IB will combine the data passed in the
GETACCT and CHARGE APIs to form the charge message that will ultimately
be passed to the COTS billing system via VDEF.
CHARGE LOCATION additions:
1. In the OUTPATIENT SITE file (#59), a new CHARGE LOCATION field
(#1007) was added, and this field is a pointer to HOSPITAL LOCATION file
(#44).
the appropriate time with the release of a subsequent Integrated Billing
2. The Site Parameter Enter/Edit [PSO SITE PARAMETERS] option input
template PSO SITE was modified to accommodate entry of the new CHARGE
LOCATION field (#1007).
3. If a CHARGE LOCATION is not defined for a particular division, the
system will loop through all divisions in the OUTPATIENT SITE file (#59)
and will use the first CHARGE LOCATION it finds. When none of the
divisions have a CHARGE LOCATION defined, the prescription will not be
passed to IB or the COTS billing system. This issue will be addressed in
System (PFSS) project. PFSS patches are being released on various
patch.
a subsequent phase of the PFSS project. Until that time, it is imperative
that CHARGE LOCATION are defined for each division.
The Integration Agreement (IA) #4732 was created to facilitate
modifications being made by IB for interfacility copay. It will be used
in the background to return the pharmacist, person who last edited the
prescription fill, and the value of the IB SERVICE/SECTION field (#1003)
from the OUTPATIENT SITE file (#59).
For more information about the PFSS project, review the documentation
accompanying this patch and refer to the following website:
http://vista.domain.ext/billreplace/.
This Outpatient Pharmacy patch, PSO*7*201 provides the functionality
needed to support the PFSS project. Note that this patch depends on
patches PSN*4*103 and PSS*1*92 to provide the new Charge Description
Master (CDM) functionality. The CDM provides Service Codes for each drug,
schedules. Some patch functionality will not be active until a new PFSS
supply item, etc. to uniquely identify them to the new COTS billing
system. This information is passed via IB Application Program Interface
(API) calls, which is explained in the Technical Description.
Functional Description:
=======================
Outpatient Pharmacy was modified to check the status of the PFSS
switch. If the PFSS switch is not activated, the current Integrated
Billing (IB) billing process will continue. If the PFSS switch is
switch is activated during final implementation. PFSS will initially be
activated, prescription and copay information will be passed to the new
COTS billing system for final copay assessments and billing via IB.
As is currently the case with IB, the exchange of information will take
place in the background with no user impact.
Upon entering a new prescription order, copying, renewing, or editing
an order that causes a new order to be created, a PFSS Account Reference
will be requested at finish from IB. This reference is used to uniquely
identify the prescription in the COTS billing system.
implemented at select pilot sites ONLY.
At prescription release, a unique charge identifier will be requested
from IB, and it will serve to uniquely identify the fill in IB. Next, a
charge message will be sent to the COTS billing system via IB. This
includes the release of Consolidated Mail Outpatient Pharmacy (CMOP)
prescriptions and prescriptions released by the Outpatient Pharmacy
Automation Interface (OPAI) functionality.
For return to stocks, and deletes that perform a return to stock, a charge
credit message will be sent.
When Service Connection and/or Environmental Indicators are modified
without a change in copay using the Reset Copay Status/Cancel Charges
[PSOCP RESET COPAY STATUS] option, a charge update message will be sent.
A charge credit message will be sent when copay charges are cancelled.
When the fill is changed to copay, no message will be sent because this
change is considered to be for the future fills.
No messaging will take place for discontinued orders. When a
discontinued order is reinstated, the previously obtained PFSS Account
Reference will be used.
The purpose of the PFSS project is to prepare the Veterans Health
In order to maintain the display of the "$" sign on the Medication
Profile screen that indicates the prescription is eligible for copay, IB
will continue to be utilized for the copay eligibility assessment that is
performed at finish. Also, the Outpatient Pharmacy and IB copay
evaluations performed at release for Service Connection, Environmental
Indicators, Drug Enforcement Agency (DEA) special handling (supply items
and investigational drugs), income exempt, and RX Patient Status checks
have not changed and will continue to be used. However, the final copay
billing determination will be performed by the COTS billing system, and
Information Systems and Technology Architecture (VistA) environment for
the final decision is based on the above information, interfacility copay
information, and current IB billing rules. There will be no return
messaging from the COTS billing system to Outpatient Pharmacy.
When Days Supply is edited on a released prescription, a charge update
message will be sent to the COTS billing system, and it is understood that
the COTS billing system will pick up the latest charge update.
Last, a new CHARGE LOCATION field (#1007) was added to the OUTPATIENT
SITE file (#59). This field will be used by the COTS billing system
the implementation of a Commercial Off-The-Shelf (COTS) billing
to group charges by division. Upon installation and before the PFSS
switch is turned on, the user will need to enter an Outpatient Pharmacy
charge location in the HOSPITAL LOCATION file (#44), and afterward define
this location in the new CHARGE LOCATION field (#1007) in the OUTPATIENT
SITE file (#59). The Site Parameter Enter/Edit [PSO SITE PARAMETERS]
option may be used to define the CHARGE LOCATION in the OUTPATIENT
SITE file (#59). A charge location should be defined for each division in
the OUTPATIENT SITE file (#59). It is suggested that this field be
coordinated with the Medical Center's billing office and the activation of
the PFSS functionality. If at least one division has a CHARGE LOCATION
|
